> Sounds more like a distribution problem and less of a linux problem.
It's neither. The vulnerabilities are in third-party scripts that are not, as far as the article indicates, part of the default install on any distribution. (That's why it's not widespread.) The reason "Linux" was mentioned is just because the worm's code happens to have been compiled for that kernel.
> Seeing as how the gum probably doesn't contain fluoride
You should be getting fluoride in your tapwater, if you live in the civilized world, so having it in the gum or the toothpaste is largely moot in that case. (If you *don't* have fluoridated water, that is as bad for your teeth as not brushing; put the two together and you've got a recipe for root canals.)
> On a serious note, there's currently no valid suggestions as to what we can do about global > warming. People are still arguing about whether or not it exists
Okay, let's suppose, hypothetically, for the sake of argument, that it does exist, and then we can get on to arguing about whether we *should* do anything about it. We'll have to settle that before there's much point in discussing *specific* actions...
I mean, *why* should we try to stop global warming? We know from paleontology that the earth was, at one time, rather more of a greenhouse than it is now. Maybe the current state of affairs is the problem, and letting things get back closer to the way they were is part of a solution. Sure, people who live below sea level will have to move, but isn't it pretty selfish to think only in terms of our man-made dwelling places, when we're talking about global climate? What if the biosphere would be overall better off with a greenhouse effect? What if that climate would be more conducive, on average, to the survivability of the genomes of various kinds of organisms? You speak of "valid" suggestions, but what if any suggestion that we "do something about" global warming is inherently invalid?
The ethics of undertaking organized action to attempt to reverse the current global trend in climate change are seriously problematic. Maybe we should just leave it alone and, instead of trying to *change* it, start thinking about how we can *adapt* to it.
(No, I'm not _entirely_ serious about this. But it's something to think about.)
Actually, you could still get burned that way. (Financially, I mean.) If a positive feedback loop of increasing amounts of water vapor in the atmosphere really does develop, people will have to make all sorts of adjustments (you know, minor little things like moving everybody out of the Netherlands), but in terms of ultraviolet radiation, we could actually end up better shielded than we are now. Water vapor is almost as good as ozone for blocking that stuff; put a third of the world's water supply in the upper troposphere or higher, and you might not *need* sunblock anymore. Nor coats, hats, and mittens.
A larger concern would be what it would do to the atmospheric currents, i.e., prevailing wind systems. Currently fertile areas could potentially end up with extended droughts and famines, the sort of thing you read about in the Revelation. Sunblock won't solve that.
Your ssh remote login *will* get noticed by port scanners, and both dictionary and brute force attacks will be made against it, particularly if it is running on the standard port (22 IIRC). You can help the attackers to compromise your system if any of the passwords of any of the users who can log in in this fashion -- especially passwords on accounts the attackers can guess must exist, such as your own preferred username or an account that is usually present on most systems, and extra-especially the root account -- are attackable via dictionary or brute force. For instance, if one of these users has a password that is only ten characters long and contains only letters, that is a potential point of entry onto your network. On the other hand, if you want to *prevent* them from getting in, use passwords that are longer, contain non-alphabetic characters, and not based on dictionary words (but pronounceable so that you can easily remember them), e.g., passwords like Frolliga_Bruckenovich or grazzivian-CHOXXI or SpoyBan8CritNox or cetera. (I don't mean these specific examples, but hopefully you get the idea -- passwords that are hard to brute-force don't have to be hard to remember. The more paranoid you are, the more syllables you add, and remember that a certain amount of paranoia is part of any sysadmin's job description.)
Another thing you could do to allow attackers to gain access is to completely ignore security bulletins and never install updates.
You've got to be kidding, a substitution cipher? Any CS student who can't break that in five minutes is in serious need of a counsellor to tell him to change majors. That's third-grade puzzle-book stuff you're talking about.
And, quite aside from that, modifying perl is completely unnecessary for that; anyone who knows much Perl could do it trivially with a source filter.
> Those dudes had a fairly nasty pack/unpack decryption sequence in their pay webmail system > that I never got around to cracking.
A student who knows Perl and has a long weekend on his hands can buzz through that sort of thing with ease, or a student with a bit less Perl knowledge could post it on the Perlmonks Obfuscated Code section and claim it's "unbreakable", practically guaranteeing it would be broken within fifteen minutes. (Deobfuscation is a recreational activity for some people, and obfuscated Perl code is incredibly susceptible to it, especially if the obfuscation is automatic, as with the sort of thing you're talking about; in fact, for someone who's reached the point of thinking in Perl, obfuscated Perl code is almost easier to read than normal code in another language (such as C).)
My last idea (a bit extreme, I would think) would be to modify the Perl interpreter to run the perl code through a decryption algorithm first (so the source on disk would be encrypted so it couldn't be read). With open source software, there is no reason this isn't possible (would hurt performance though). Does Perl support some kind of tolkenizing?
<p>Yeah, this is called a source filter. There are a large number of them on the CPAN. They're all done for fun-related purposes, mostly humor. Some examples include ACME::Bleach (the program is encoded entirely in whitespace), or ACME::Buffy (for vampire fans), and ACME::Eyedrops (my personal favorite, and different from the others in that the module doesn't have to be installed on the system where the code is to be executed; it produces code that abuses (severely) the regular expression engine to accomplish what the original code accomplished). </p>
<p>However, none of these will prevent someone with full access to the system, who understands Perl, from being able to reverse the process and demangle the code to obtain it in the form the interpreter sees. And yes, there's a performance hit, although with most of them (notably excepting Eyedrops) it's upfront (when the program is first launched), not continuous (thoughout the execution of the program), so it's not as bad as you might think. </p>
> Think I'm kidding, my niece had a science project > fail because the document produced in Open Office > didn't produce on his MS Word a lower margin of 1 > inch, it created a lower margin of 1.25 inches, > yes the idiot used a ruler. When he was told that > the document was produced in Open Office, his > response was "What's that? I said to use > Microsoft Word!"
The office software being used is entirely a red herring here. Requiring specific margins is standard practice throughout academia at all grade levels, from the primary grades through to the post-graduate level, and one inch is by *far* the most common requirement. Students are *continually* trying to get away with slightly larger margins than are required (and slightly larger fonts than the teacher specifies, and slightly more than the amount of line spacing requested, and various other schenanighans) in order to "fill up" page requirements with fewer words; this, completely irrespective of software issues, is *always* grounds for downgrading.
On the one hand the teacher shouldn't be requiring a specific software product, but on the other hand the teacher doesn't want to hear inane and irrelevant comments like "I used such-and-such software" as an excuse for using excessively large margins. His response *should* have been, "You need to use software that supports setting the margins to one inch." (Which OO does support, of course, but the student implied otherwise.) So his response was not worded well. But, if you assumed that the student's bizarre implication were correct, it would ammount, roughly, to a paraphrase. The teacher also should have known better than to assume the student's implication was correct, but if he does take a student's remark at face value, the student really has no valid grounds for complaint.
Getting back to the software: I have wondered for a long time why the default margins in OpenOffice are so enormously large, but really it's neither here nor there. When you're doing a paper for school, you always need to check your margins anyway, to verify that they're correct. Not doing so is always grounds for downgrading, period. Trying to excuse it by explaining that OpenOffice was used is... well, let's just call it something the student needs to learn not to do and leave it at that.
> I've never had a problem with incompatibility > between version of MS Office
Ah, I see you live in that portion of society where things are upgraded in a timely fashion, so that you have not experienced the pain of attempting to take a document someone sent you that was created with Office 2003 and help a colleague open it on a computer that still has Office 4.3. (If you suggest an upgrade, said colleague gives you a dirty look and commences ninety solid minutes of bemoaning the horrors the previous upgrade, with all the user-interface changes it entailed, and extolling the virtues of Lotus 123 for DOS. Eventually you tell the colleague to just save the stupid document on a floppy diskette, so you can take it and print it on a computer that's a bit more up to date.)
With that said, there *are* some concrete benefits to the OpenDocument format, not least of all because it's *much* easier to generate with custom software. For instance, if you've got a database on your intranet containing names and addresses with a DBI/CGI frontend, it's easy to add a "generate mailing labels" feature that returns an OpenOffice document to the user; you can easily spend more time choosing the font so forth and setting up the formatting in your template than it takes to write the code that plugs in the data and returns the result. No, I don't expect the average home user to appreciate this sort of thing, but IT departments might think it's pretty cool.
> The continued use of the proprietary Microsoft formats > benefit me because that's what just about everyone is > already set up for.
That's either circular, or more likely you misunderstood what the other poster meant by "the continued use". Perhaps you thought he was talking about *your* continued use; he wasn't. He was talking about the continued *widespread* use, i.e., the continuance of the overall situation wherein just about everyone is already set up, more-or-less exclusively, for proprietary document formats. If this situation changes to the extent that just about everyone is set up for an open format, the only *potential* inconvenience that could cause you is that you would need to upgrade to stay compatible, but that would happen anyway with a future revision of Microsoft's proprietary formats, as has happened numerous times in the past; indeed, it is already poised to get underway again with Microsoft's XML-based formats, which are intended eventually to supercede the binary ones, assuming something else (like OpenDocument) doesn't supercede both first.
The argument that the other poster was making, although perhaps he wasn't sufficiently clear, was to the effect that there is no benefit to you if the next format that "just about everyone" upgrades to (and you therefore need to upgrade to as well) is a future version of Microsoft's proprietary format, versus some other format. If you only use the existing MS format because that's what everyone else uses, then you are not part of the group he was arguing against. He was talking about people who specifically don't want any non-Microsoft format or technology to gain widespread adoption.
> Apple, on the other hand, has been downright hostile > towards the OOo folks, telling them in no uncertain > terms that Apple does not wish to make it easier to > run X11 on OS X and does not wish other people to > make it easier. Apple wants everybody to port to > their proprietary GUI and they are going to do > whatever it takes to "motivate" people to do that.
This does not, however, preclude that they might add input filters to their own existing office software suites (AppleWorks (if they are still maintaining that) and iWork), as they did a couple versions back for Microsoft's (binary) document formats. There is (for now) probably less demand for OpenDocument formats, but OTOH they should be rather easier to implement, since they are non-binary and also fully specified. I wouldn't care to hazzard a guess on timeframe, but support for OpenDocument formats in any future version of Apple's own office software would not surprise me in the least.
> I write code for a Windows app for a living and feel > the need to point out that even just limited to > Windows, our code has to be aware of the different > Windows versions.
Yeah, and how do you know your code will run on the next version of Windows, and the version after that? Do you know what's going to change? How can you?
You can work around the differences in known versions, but if your code is unportable, the next change could break it.
Write *portable* code, get it running on at least four really distinct platforms (Windows, Mac, VMS, and Linux would be a good start -- and I'm talking about getting the *same* code running on all the platforms, not four different branches of #IFDEF), and then in 2012 when Windows Conversation comes out, or whatever oddball name they give the next one after Vista, you'll be ready.
There will, of course, be a few small bits of code that have to be written differently for each platform; these you put in separate, platform-specific files, and you keep them as short as possible, and then when you have to port to the next Windows -- or whatever you port to -- those are hopefully the only parts you have to rewrite.
Amiga? Bah! I want to run it on a Texas Instruments calculator, a BBC micro, or Nintendo Gameboy. Writing C code won't get you anywhere here; you need a language with *real* portability.
Java is middle-of-the-road for portability. (So is Perl. I don't really know where Ruby falls on this.) Although more platforms have a C compiler, Java code is more portable from one of those platforms to another, in general, than C code. It is *possible* to write C code that is more portable than Java, but it is highly unusual.
I would rate Perl as more portable than Java as long as you don't do stupidly unportable things (hardcode filepaths, call system binaries, that sort of nonsense) or need to provide a GUI; Java handles the GUI rather better than Perl, however. (Any kind of GUI is inherently far less portable than a command-line program, and inherently you will support fewer platforms (typically only Win32, Mac, X11 on POSIX, and possibly OS/2 or BeOS), but sometimes it's a requirement.) Again, I don't know where Ruby falls on this.
I strongly suspect, from the other poster's comment, that he was assuming the application in question needed a GUI, because if we add that assumption into the mix, his comment makes a lot more sense than otherwise.
Perl is fairly portable, if you need amenities like access to the filesystem and the ability to allocate memory dynamically. If you can do without such niceties, it's possible to be *MUCH* more portable, e.g. by programming in Inform and compiling to z3.
> Bar none, if you want to write something portable, > Java is the language to use.
"Bar none" is awefully strong language. I would have said that Java was middle-of-the-road in terms of portability. It's more portable than any of the other languages you expressly list, sure, but those are mostly fairly unportable langauges. Java is better, but in terms of extreme portability, it is not a contender.
There are a *lot* of platforms with no Java vm: most of the 8-bit micros, most of the older handhelds, as well as most of the lighter handhelds, some game consoles, most of the older non-micro systems,...
If you write in Inform, you compile once and run on any of those, as well as, of course, anything with a Java VM, anything with Perl 5.003 or later, anything with Emacs 20 or later, Texas Instruments calculators, and practically anything else.
Granted, these are all systems you typically don't need to support with e.g. a desktop business application, so for that sort of thing Java is a good choice, especially if GUI is important, as Java handles that rather nicely (and Perl, another midrange system in terms of portability and my personal preference for almost anything command-line oriented, is particularly weak for GUI stuff). And Inform is not a choice at *all* if you need a GUI or any of a number of other features it doesn't support. On the other hand, if really extreme portability is needed, Java is not a choice at all.
> True universal portability is a Holy Grail that > we'll never attain
If you're willing to accept the limitations that go along with writing to the least common denominator, Inform comes *really* close to true universal portability -- compile once, run anywhere that has the VM, which is *almost* anywhere. You can, for instance, use the same z3 module on the PDP10, Palm and Psion handhelds, Nintendo Gameboy, Atari ST, TRS80, the BBC micro, Acorn/Archimedes/RiscOS, and a *wide* assortment of other systems (including, of course, all the major ones: DOS, Windows, Mac, Apple II, Amiga, pretty much any POSIX system, anything with Perl5 or a Java vm, Emacs, Mozilla (with XUL),...). There is not a complete list anywhere of the platforms that have a z-code interpreter available, but I strongly suspect that it is the third most widely-supported computer format after ASCII and HTML (which are nothing like equivalent in their capabilities (z-code is not some kind of glorified markup; Inform is a very nice language to work in, with extensive object-oriented features), and HTML is nowhere near as consistent in how it is rendered; even ASCII isn't if you consider line-ending differences or other characters outside the range of 32-127 (decimal)). For instance, given the number of platforms with no graphics capability, I cannot imagine that GIF is as widely portable as z3, although it is surely more widely-known.
If you need the extra memory afforded by z5, the list shortens a little; if you need graphics (z6) or even more memory (z8), the list shortens rather more, but is still fairly impressive.
Re:Write and test on three different platforms
on
Write Portable Code
·
· Score: 1
> I agree, if you write for portability on just two > platforms, say Windows and Linux, porting to anything > else becomes that much easier.
This is more true if the two platforms are more different from one another. If possible, they should have completely different concepts of filesystem structure, use different byte orders (big-endian versus little), have different numbers of bits in the basic data types, one should be heavily multi-user with a detailed security and permissions model and the other not, and so on and so forth. MacOS 9 on PPC and VMS on Vax, for instance, would make a good pair. Anything that compiles and runs without modification on both of those should be *nicely* portable.
> Cross platform as long as it's Windows or *nix. How about zSeries, iSeries, HP NonStop, etc.
When you need that kind of portability, you program in Inform and compile to z3. Then you can run it on everything from the PDP10 to Nintendo Gameboy.
The downside of this is that there are certain limitations. For instance, due to the need to run on platforms that don't have a filesystem, your file I/O functionality is limited to save (all read-write memory in one go to a user-specified location; tiny platforms may have only one location), restore (all read-write memory in one go from a user-specified location; same caveat), and start or stop logging the I/O to a transcript.
Still, it's impressive how many things you *can* do within the limitations imposed by extreme portability.
Re:C++ is cross-platform, dont know what your smok
on
Write Portable Code
·
· Score: 1
> For example, data serialization - if I care about a piece of > code being portable, all of my "structures" that may need to > be shared are classes with the functions "serialize" and > "deserialize", and all of the member variables/structures are > classes with such functions (down to the most simple members, > which are just wrappers around basic types; you can even wrap > vectors and maps so that arrays of any kind are dealt with > automatically). Each class's serialize function simply calls > the serialize function on all of its members that need to be > preserved; only the most basic types actually do any IO themselves.
Wow, all that work, and here all along I've just been using Data::Dumper for this sort of thing. (Granted, if you have lexical closures this doesn't preserve their lexical context, but I don't think that would work with your C++ serialization system either.)
Indeed, and this will become even more true in the coming months, because Python will run on Parrot, so that way you'll be able to use modules off the CPAN...
> Does this "worm" also work on Solaris, HPUX, AIX, > and other apache and php aware operating systems?
This specific worm in its current form does not, because its binary is Linux-specific. However, the vulnerabilities that this worm exploits are in specific scripts, and the vulnerabilities are probably present on all platforms that those scripts support, which almost certainly includes more than just Linux, meaning that the worm could be modified to work on those platforms.
However, since the worm is not at all widespread running on Linux systems, I rather doubt making it work with HPUX or AIX will make it much more widespread.
> sounds like a new version of the formmail.pl problem.
> No, PHP is secure. Some applications written in PHP are insecure.
s/some/most/;
It is true (at least for the most part) that programmers who understand security do not need to be afraid of programming in PHP, any more than any other language.
The reason *more* PHP apps are insecure than others is primarily because a lot of people pick up PHP with no former programming background at *all*. It looks (vaguely) like HTML, so they have the confidence to start programming. This would not be a big deal, except that then some of them *distribute* what they have done and *other* people use it. The Perl world has Matt's Script Archive, which is infamous, but in the PHP world there's a *LOT* of this sort of thing going on.
There is also one additional issue, not related per-se to the language but nevertheless PHP specific in that it is related to the PHP software and the way it is normally installed, an issue that has an impact on the defense in depth of systems with PHP installed. Namely, the server will (at least typically) happily execute PHP scripts from *any* (served) directory, not just specific ones, and it will do so even if those scripts do not have their execute bit set at the filesystem level. This is, IMO, a design flaw from a security perspective, and should be changed; PHP execution/interpretation should be enabled on a per-directory or per-subtree basis, and individual files should NOT be executed or interpreted by PHP unless they have their execute permission set. The Open Clip Art Library was not long ago bitten by an interaction between this issue and an overly-permissive submission upload script; the upload script is being corrected, but correcting both would provide better defense in depth.
> I doubt I'll have the libraries required to run this worm.
Oh, you'll have the right libraries, but that's not enough; you have to have the latest and greatest _versions_ of each of them. For instance, you need Pango 1.10.2 or higher; if you're still using an earlier release of Pango, you'll have to install the latest one, which will also require you to upgrade your X server to x.Org 6.8.3 or later. Note also that if you have an ATI or nVidia graphics card, or certain models of Matrox cards, the drivers have not yet been updated for 6.8.3, so you will have to wait for that. Also you will need a glibc version that is current from CVS within the last couple of weeks.
Slashdot Mirror
> Sounds more like a distribution problem and less of a linux problem.
It's neither. The vulnerabilities are in third-party scripts that are not, as far as the article indicates, part of the default install on any distribution. (That's why it's not widespread.) The reason "Linux" was mentioned is just because the worm's code happens to have been compiled for that kernel.
> Seeing as how the gum probably doesn't contain fluoride
You should be getting fluoride in your tapwater, if you live in the civilized world, so having it in the gum or the toothpaste is largely moot in that case. (If you *don't* have fluoridated water, that is as bad for your teeth as not brushing; put the two together and you've got a recipe for root canals.)
> On a serious note, there's currently no valid suggestions as to what we can do about global
> warming. People are still arguing about whether or not it exists
Okay, let's suppose, hypothetically, for the sake of argument, that it does exist, and then we can get on to arguing about whether we *should* do anything about it. We'll have to settle that before there's much point in discussing *specific* actions...
I mean, *why* should we try to stop global warming? We know from paleontology that the earth was, at one time, rather more of a greenhouse than it is now. Maybe the current state of affairs is the problem, and letting things get back closer to the way they were is part of a solution. Sure, people who live below sea level will have to move, but isn't it pretty selfish to think only in terms of our man-made dwelling places, when we're talking about global climate? What if the biosphere would be overall better off with a greenhouse effect? What if that climate would be more conducive, on average, to the survivability of the genomes of various kinds of organisms? You speak of "valid" suggestions, but what if any suggestion that we "do something about" global warming is inherently invalid?
The ethics of undertaking organized action to attempt to reverse the current global trend in climate change are seriously problematic. Maybe we should just leave it alone and, instead of trying to *change* it, start thinking about how we can *adapt* to it.
(No, I'm not _entirely_ serious about this. But it's something to think about.)
Actually, you could still get burned that way. (Financially, I mean.) If a positive feedback loop of increasing amounts of water vapor in the atmosphere really does develop, people will have to make all sorts of adjustments (you know, minor little things like moving everybody out of the Netherlands), but in terms of ultraviolet radiation, we could actually end up better shielded than we are now. Water vapor is almost as good as ozone for blocking that stuff; put a third of the world's water supply in the upper troposphere or higher, and you might not *need* sunblock anymore. Nor coats, hats, and mittens.
A larger concern would be what it would do to the atmospheric currents, i.e., prevailing wind systems. Currently fertile areas could potentially end up with extended droughts and famines, the sort of thing you read about in the Revelation. Sunblock won't solve that.
Your ssh remote login *will* get noticed by port scanners, and both dictionary and brute force attacks will be made against it, particularly if it is running on the standard port (22 IIRC). You can help the attackers to compromise your system if any of the passwords of any of the users who can log in in this fashion -- especially passwords on accounts the attackers can guess must exist, such as your own preferred username or an account that is usually present on most systems, and extra-especially the root account -- are attackable via dictionary or brute force. For instance, if one of these users has a password that is only ten characters long and contains only letters, that is a potential point of entry onto your network. On the other hand, if you want to *prevent* them from getting in, use passwords that are longer, contain non-alphabetic characters, and not based on dictionary words (but pronounceable so that you can easily remember them), e.g., passwords like Frolliga_Bruckenovich or grazzivian-CHOXXI or SpoyBan8CritNox or cetera. (I don't mean these specific examples, but hopefully you get the idea -- passwords that are hard to brute-force don't have to be hard to remember. The more paranoid you are, the more syllables you add, and remember that a certain amount of paranoia is part of any sysadmin's job description.)
Another thing you could do to allow attackers to gain access is to completely ignore security bulletins and never install updates.
You've got to be kidding, a substitution cipher? Any CS student who can't break that in five minutes is in serious need of a counsellor to tell him to change majors. That's third-grade puzzle-book stuff you're talking about.
And, quite aside from that, modifying perl is completely unnecessary for that; anyone who knows much Perl could do it trivially with a source filter.
> Those dudes had a fairly nasty pack/unpack decryption sequence in their pay webmail system
> that I never got around to cracking.
A student who knows Perl and has a long weekend on his hands can buzz through that sort of thing with ease, or a student with a bit less Perl knowledge could post it on the Perlmonks Obfuscated Code section and claim it's "unbreakable", practically guaranteeing it would be broken within fifteen minutes. (Deobfuscation is a recreational activity for some people, and obfuscated Perl code is incredibly susceptible to it, especially if the obfuscation is automatic, as with the sort of thing you're talking about; in fact, for someone who's reached the point of thinking in Perl, obfuscated Perl code is almost easier to read than normal code in another language (such as C).)
<p>Yeah, this is called a source filter. There are a large number of them on the CPAN. They're all done for fun-related purposes, mostly humor. Some examples include ACME::Bleach (the program is encoded entirely in whitespace), or ACME::Buffy (for vampire fans), and ACME::Eyedrops (my personal favorite, and different from the others in that the module doesn't have to be installed on the system where the code is to be executed; it produces code that abuses (severely) the regular expression engine to accomplish what the original code accomplished).
</p>
<p>However, none of these will prevent someone with full access to the system, who understands Perl, from being able to reverse the process and demangle the code to obtain it in the form the interpreter sees. And yes, there's a performance hit, although with most of them (notably excepting Eyedrops) it's upfront (when the program is first launched), not continuous (thoughout the execution of the program), so it's not as bad as you might think.
</p>
> Think I'm kidding, my niece had a science project
> fail because the document produced in Open Office
> didn't produce on his MS Word a lower margin of 1
> inch, it created a lower margin of 1.25 inches,
> yes the idiot used a ruler. When he was told that
> the document was produced in Open Office, his
> response was "What's that? I said to use
> Microsoft Word!"
The office software being used is entirely a red herring here. Requiring specific margins is standard practice throughout academia at all grade levels, from the primary grades through to the post-graduate level, and one inch is by *far* the most common requirement. Students are *continually* trying to get away with slightly larger margins than are required (and slightly larger fonts than the teacher specifies, and slightly more than the amount of line spacing requested, and various other schenanighans) in order to "fill up" page requirements with fewer words; this, completely irrespective of software issues, is *always* grounds for downgrading.
On the one hand the teacher shouldn't be requiring a specific software product, but on the other hand the teacher doesn't want to hear inane and irrelevant comments like "I used such-and-such software" as an excuse for using excessively large margins. His response *should* have been, "You need to use software that supports setting the margins to one inch." (Which OO does support, of course, but the student implied otherwise.) So his response was not worded well. But, if you assumed that the student's bizarre implication were correct, it would ammount, roughly, to a paraphrase. The teacher also should have known better than to assume the student's implication was correct, but if he does take a student's remark at face value, the student really has no valid grounds for complaint.
Getting back to the software: I have wondered for a long time why the default margins in OpenOffice are so enormously large, but really it's neither here nor there. When you're doing a paper for school, you always need to check your margins anyway, to verify that they're correct. Not doing so is always grounds for downgrading, period. Trying to excuse it by explaining that OpenOffice was used is... well, let's just call it something the student needs to learn not to do and leave it at that.
> I've never had a problem with incompatibility
> between version of MS Office
Ah, I see you live in that portion of society where things are upgraded in a timely fashion, so that you have not experienced the pain of attempting to take a document someone sent you that was created with Office 2003 and help a colleague open it on a computer that still has Office 4.3. (If you suggest an upgrade, said colleague gives you a dirty look and commences ninety solid minutes of bemoaning the horrors the previous upgrade, with all the user-interface changes it entailed, and extolling the virtues of Lotus 123 for DOS. Eventually you tell the colleague to just save the stupid document on a floppy diskette, so you can take it and print it on a computer that's a bit more up to date.)
With that said, there *are* some concrete benefits to the OpenDocument format, not least of all because it's *much* easier to generate with custom software. For instance, if you've got a database on your intranet containing names and addresses with a DBI/CGI frontend, it's easy to add a "generate mailing labels" feature that returns an OpenOffice document to the user; you can easily spend more time choosing the font so forth and setting up the formatting in your template than it takes to write the code that plugs in the data and returns the result. No, I don't expect the average home user to appreciate this sort of thing, but IT departments might think it's pretty cool.
> The continued use of the proprietary Microsoft formats
> benefit me because that's what just about everyone is
> already set up for.
That's either circular, or more likely you misunderstood what the other poster meant by "the continued use". Perhaps you thought he was talking about *your* continued use; he wasn't. He was talking about the continued *widespread* use, i.e., the continuance of the overall situation wherein just about everyone is already set up, more-or-less exclusively, for proprietary document formats. If this situation changes to the extent that just about everyone is set up for an open format, the only *potential* inconvenience that could cause you is that you would need to upgrade to stay compatible, but that would happen anyway with a future revision of Microsoft's proprietary formats, as has happened numerous times in the past; indeed, it is already poised to get underway again with Microsoft's XML-based formats, which are intended eventually to supercede the binary ones, assuming something else (like OpenDocument) doesn't supercede both first.
The argument that the other poster was making, although perhaps he wasn't sufficiently clear, was to the effect that there is no benefit to you if the next format that "just about everyone" upgrades to (and you therefore need to upgrade to as well) is a future version of Microsoft's proprietary format, versus some other format. If you only use the existing MS format because that's what everyone else uses, then you are not part of the group he was arguing against. He was talking about people who specifically don't want any non-Microsoft format or technology to gain widespread adoption.
> Apple, on the other hand, has been downright hostile
> towards the OOo folks, telling them in no uncertain
> terms that Apple does not wish to make it easier to
> run X11 on OS X and does not wish other people to
> make it easier. Apple wants everybody to port to
> their proprietary GUI and they are going to do
> whatever it takes to "motivate" people to do that.
This does not, however, preclude that they might add input filters to their own existing office software suites (AppleWorks (if they are still maintaining that) and iWork), as they did a couple versions back for Microsoft's (binary) document formats. There is (for now) probably less demand for OpenDocument formats, but OTOH they should be rather easier to implement, since they are non-binary and also fully specified. I wouldn't care to hazzard a guess on timeframe, but support for OpenDocument formats in any future version of Apple's own office software would not surprise me in the least.
> That's because it's... Thursday. The last time something like that happened was on a Wednesday.
I've noticed it also tends to happen on Tuesdays and Fridays.
> I write code for a Windows app for a living and feel
> the need to point out that even just limited to
> Windows, our code has to be aware of the different
> Windows versions.
Yeah, and how do you know your code will run on the next version of Windows, and the version after that? Do you know what's going to change? How can you?
You can work around the differences in known versions, but if your code is unportable, the next change could break it.
Write *portable* code, get it running on at least four really distinct platforms (Windows, Mac, VMS, and Linux would be a good start -- and I'm talking about getting the *same* code running on all the platforms, not four different branches of #IFDEF), and then in 2012 when Windows Conversation comes out, or whatever oddball name they give the next one after Vista, you'll be ready.
There will, of course, be a few small bits of code that have to be written differently for each platform; these you put in separate, platform-specific files, and you keep them as short as possible, and then when you have to port to the next Windows -- or whatever you port to -- those are hopefully the only parts you have to rewrite.
> Do you have a link to the Amiga port?
Amiga? Bah! I want to run it on a Texas Instruments calculator, a BBC micro, or Nintendo Gameboy. Writing C code won't get you anywhere here; you need a language with *real* portability.
Java is middle-of-the-road for portability. (So is Perl. I don't really know where Ruby falls on this.) Although more platforms have a C compiler, Java code is more portable from one of those platforms to another, in general, than C code. It is *possible* to write C code that is more portable than Java, but it is highly unusual.
I would rate Perl as more portable than Java as long as you don't do stupidly unportable things (hardcode filepaths, call system binaries, that sort of nonsense) or need to provide a GUI; Java handles the GUI rather better than Perl, however. (Any kind of GUI is inherently far less portable than a command-line program, and inherently you will support fewer platforms (typically only Win32, Mac, X11 on POSIX, and possibly OS/2 or BeOS), but sometimes it's a requirement.) Again, I don't know where Ruby falls on this.
I strongly suspect, from the other poster's comment, that he was assuming the application in question needed a GUI, because if we add that assumption into the mix, his comment makes a lot more sense than otherwise.
Perl is fairly portable, if you need amenities like access to the filesystem and the ability to allocate memory dynamically. If you can do without such niceties, it's possible to be *MUCH* more portable, e.g. by programming in Inform and compiling to z3.
> Bar none, if you want to write something portable,
...
> Java is the language to use.
"Bar none" is awefully strong language. I would have said that Java was middle-of-the-road in terms of portability. It's more portable than any of the other languages you expressly list, sure, but those are mostly fairly unportable langauges. Java is better, but in terms of extreme portability, it is not a contender.
There are a *lot* of platforms with no Java vm: most of the 8-bit micros, most of the older handhelds, as well as most of the lighter handhelds, some game consoles, most of the older non-micro systems,
If you write in Inform, you compile once and run on any of those, as well as, of course, anything with a Java VM, anything with Perl 5.003 or later, anything with Emacs 20 or later, Texas Instruments calculators, and practically anything else.
Granted, these are all systems you typically don't need to support with e.g. a desktop business application, so for that sort of thing Java is a good choice, especially if GUI is important, as Java handles that rather nicely (and Perl, another midrange system in terms of portability and my personal preference for almost anything command-line oriented, is particularly weak for GUI stuff). And Inform is not a choice at *all* if you need a GUI or any of a number of other features it doesn't support. On the other hand, if really extreme portability is needed, Java is not a choice at all.
> True universal portability is a Holy Grail that
...). There is not a complete list anywhere of the platforms that have a z-code interpreter available, but I strongly suspect that it is the third most widely-supported computer format after ASCII and HTML (which are nothing like equivalent in their capabilities (z-code is not some kind of glorified markup; Inform is a very nice language to work in, with extensive object-oriented features), and HTML is nowhere near as consistent in how it is rendered; even ASCII isn't if you consider line-ending differences or other characters outside the range of 32-127 (decimal)). For instance, given the number of platforms with no graphics capability, I cannot imagine that GIF is as widely portable as z3, although it is surely more widely-known.
> we'll never attain
If you're willing to accept the limitations that go along with writing to the least common denominator, Inform comes *really* close to true universal portability -- compile once, run anywhere that has the VM, which is *almost* anywhere. You can, for instance, use the same z3 module on the PDP10, Palm and Psion handhelds, Nintendo Gameboy, Atari ST, TRS80, the BBC micro, Acorn/Archimedes/RiscOS, and a *wide* assortment of other systems (including, of course, all the major ones: DOS, Windows, Mac, Apple II, Amiga, pretty much any POSIX system, anything with Perl5 or a Java vm, Emacs, Mozilla (with XUL),
If you need the extra memory afforded by z5, the list shortens a little; if you need graphics (z6) or even more memory (z8), the list shortens rather more, but is still fairly impressive.
> I agree, if you write for portability on just two
> platforms, say Windows and Linux, porting to anything
> else becomes that much easier.
This is more true if the two platforms are more different from one another. If possible, they should have completely different concepts of filesystem structure, use different byte orders (big-endian versus little), have different numbers of bits in the basic data types, one should be heavily multi-user with a detailed security and permissions model and the other not, and so on and so forth. MacOS 9 on PPC and VMS on Vax, for instance, would make a good pair. Anything that compiles and runs without modification on both of those should be *nicely* portable.
> Cross platform as long as it's Windows or *nix. How about zSeries, iSeries, HP NonStop, etc.
When you need that kind of portability, you program in Inform and compile to z3. Then you can run it on everything from the PDP10 to Nintendo Gameboy.
The downside of this is that there are certain limitations. For instance, due to the need to run on platforms that don't have a filesystem, your file I/O functionality is limited to save (all read-write memory in one go to a user-specified location; tiny platforms may have only one location), restore (all read-write memory in one go from a user-specified location; same caveat), and start or stop logging the I/O to a transcript.
Still, it's impressive how many things you *can* do within the limitations imposed by extreme portability.
> For example, data serialization - if I care about a piece of
> code being portable, all of my "structures" that may need to
> be shared are classes with the functions "serialize" and
> "deserialize", and all of the member variables/structures are
> classes with such functions (down to the most simple members,
> which are just wrappers around basic types; you can even wrap
> vectors and maps so that arrays of any kind are dealt with
> automatically). Each class's serialize function simply calls
> the serialize function on all of its members that need to be
> preserved; only the most basic types actually do any IO themselves.
Wow, all that work, and here all along I've just been using Data::Dumper for this sort of thing. (Granted, if you have lexical closures this doesn't preserve their lexical context, but I don't think that would work with your C++ serialization system either.)
Indeed, and this will become even more true in the coming months, because Python will run on Parrot, so that way you'll be able to use modules off the CPAN...
> Does this "worm" also work on Solaris, HPUX, AIX,
> and other apache and php aware operating systems?
This specific worm in its current form does not, because its binary is Linux-specific. However, the vulnerabilities that this worm exploits are in specific scripts, and the vulnerabilities are probably present on all platforms that those scripts support, which almost certainly includes more than just Linux, meaning that the worm could be modified to work on those platforms.
However, since the worm is not at all widespread running on Linux systems, I rather doubt making it work with HPUX or AIX will make it much more widespread.
> sounds like a new version of the formmail.pl problem.
Yes, it's VERY similar to that.
> No, PHP is secure. Some applications written in PHP are insecure.
s/some/most/;
It is true (at least for the most part) that programmers who understand security do not need to be afraid of programming in PHP, any more than any other language.
The reason *more* PHP apps are insecure than others is primarily because a lot of people pick up PHP with no former programming background at *all*. It looks (vaguely) like HTML, so they have the confidence to start programming. This would not be a big deal, except that then some of them *distribute* what they have done and *other* people use it. The Perl world has Matt's Script Archive, which is infamous, but in the PHP world there's a *LOT* of this sort of thing going on.
There is also one additional issue, not related per-se to the language but nevertheless PHP specific in that it is related to the PHP software and the way it is normally installed, an issue that has an impact on the defense in depth of systems with PHP installed. Namely, the server will (at least typically) happily execute PHP scripts from *any* (served) directory, not just specific ones, and it will do so even if those scripts do not have their execute bit set at the filesystem level. This is, IMO, a design flaw from a security perspective, and should be changed; PHP execution/interpretation should be enabled on a per-directory or per-subtree basis, and individual files should NOT be executed or interpreted by PHP unless they have their execute permission set. The Open Clip Art Library was not long ago bitten by an interaction between this issue and an overly-permissive submission upload script; the upload script is being corrected, but correcting both would provide better defense in depth.
> Oh, you'll have the right libraries, but that's not enough; you
;-)
> have to have the latest and greatest _versions_ of each of them.
Incidentally, Debian users are completely immune to this worm
> I doubt I'll have the libraries required to run this worm.
Oh, you'll have the right libraries, but that's not enough; you have to have the latest and greatest _versions_ of each of them. For instance, you need Pango 1.10.2 or higher; if you're still using an earlier release of Pango, you'll have to install the latest one, which will also require you to upgrade your X server to x.Org 6.8.3 or later. Note also that if you have an ATI or nVidia graphics card, or certain models of Matrox cards, the drivers have not yet been updated for 6.8.3, so you will have to wait for that. Also you will need a glibc version that is current from CVS within the last couple of weeks.