...making Linux just a little more fun!
We're thinking of a very special edition of "Foolish Things We Do With Our Computers". If you did something foolish, or had something foolish inflicted upon you by your otherwise favored silicon lifeform, and you're willing to have just a little more fun with it in public, send it along to us.
This does not have to be in article format. You can just send it to The Answer Gang (tag, at our happy domain linuxgazette.net) with the subject "Foolish Things With Computers" and we'll gather them all up and roast marshmallows over them. Let us know if you want your name left in - we'll take these anonymously too. But don't just make them up; we want real tales that make us groan and go agh I won't do that again!
In the issues numbered about 85 to 89 we had articles about the use of voice on computers in developing areas, for hadicapped usage, and the like.
Sound systems on Linux have improved considerably - we've had Jimmy cover "Songs In the Key of Tux" - but we haven't come back to the topic of ordinary voices. Voice Over IP got a mere nod in my Answer Gang blurb last Summer.
If you are interested in writing an article on this topic, see our article submission guidelines and then drop us a line!
Sent to our author Kapil Hari Paranjape privately, printed with permission. -- Heather
and thanks for your amusing article about the Knight's tour in Linux Gazette. I don't understand Python, but I have some experience of the Knight's tour problem. Mathematicians might have annoying habits, and one could be to end their articles with Exercises Like: 4.There is apparently a better algorithm than Warnsdorff's for the Hamiltonian circuit. Find it and implement it.
"apparently" ?! Enough to drive at least me crazy
with some decently efficient Java applets and some about the research done about the problem of how many closed tours there are. (At least I would call that problem 'hard')
Once again, Thanks for your article
and Best regards
Here's a reply to my posting of the Packet Writing material on my own site. I've gotten his permission to forward this into TAG as commentary on the original, so if you want to use it... ?
Actually the time for UDF formatting of a CDRW is consistant with Nero's packet driver (InCD) under Windows. InCD used to have multiple selections of "Format" and "Quick Format" available but only the "Format" option was available for a BLANK CDRW disk and formatting could take up to 45min to an hour. A previous formatted UDF disk would let you "quick format" and take considerably less time; some times as short as 6min.
Of course, I suspect the "quick format" is really only doing a quick erase and random verify of the file system. This would be similar to a 'quick erase' of a CDRW disk which was written/formatted as an iso -- erase the header and directory structure but don't bother with rest of data (i.e. lets hope the surface, etc. is OK and we'll just overwrite for the new compilation).
I had a Mount Ranier capable CDRW drive at one point and I noticed that it worked a bit differently. Apparently MR drives can format and write "at the same time" and also do formatting in the background. So, when using MR (instead of UDF 1.5) it appeared only the disk headers and directory structure was initially formatted. Then, as data was sent to the drive (by "drag and drop" or whatever) it was cached and buffered, then the space needed was formatted and written to in the background. When the disk was ejected a significate delay occured while anything left in the cache was written out to disk and the disk cleaned up. It appeared that only as much of the disk was actually formatted as needed because you could "force" a full disk format in MR and it would take about as long to complete as a format as UDF.
Users should also be aware that UDF file systems are much, much less safe than standard iso compilations. They are more effected by heat. Not all UDF file systems are equal -- especially now that various revision levels are out (UDF1.5 appears to be "standard recommended" while there were revisions up to 2.5 last time I looked). In practice I've found that using packet writting is tends to work only for the computer/drive you write it on and only for relatively short term storage.
Note the fact that Windows XP's setup for CD writing uses a disk buffer and writes only a iso. It simulates a "drag and drop" random access file system by mapping the CDRW disk to the buffer (actually a system folder called "cd burning") and then just burns asks to burn a standard iso. For adding to a written disk it appear to load what is already on disk to the buffer adding to the new files then erase the CDRW disk and re-burn it. I suspect even good old Microsoft figured the odds of including UDF packed writing would be adding another can of worms to XP.
PS: I have been testing Xandros OC 3.0.1 and I find I like it quite a bit. I didn't find 2/2.5 really ready for an average business user but Xandros 3 looks to be a true MS desktop killer. A number of my clients are fed up with paying through the nose for Windows "upgrades" -- some really feel MS tugging the chain -- so they are very interested. I even have one office where the practice management application will run under Crossover Office -- and the developers have decided to commit to a Linux version for release next year.
This was pretty good article but it seems to leave out something. Because of that I've had hours of pain. Perhaps a note could be added.
Here is what seems to be missing: setting up AXIS_HOME, AXIS_LIB, and AXIS_CLASSPATH, as in
set AXIS_HOME=c:\axis set AXIS_LIB=%AXIS_HOME%\lib set AXISCLASSPATH=%AXIS_LIB%\axis.jar;%AXIS_LIB%\commons-discovery.jar; %AXIS_LIB%\commons-logging.jar;%AXIS_LIB%\jaxrpc.jar;%AXIS_LIB%\saaj.jar; %AXIS_LIB%\log4j-1.2.8.jar;%AXIS_LIB%\xml-apis.jar;%AXIS_LIB%\xercesImpl.jar ;%AXIS_LIB%\wsdl4j.jar
Regards and keep on going,
Forwarded from a discussion on the Linux Documentation Project mailing lists. Linux Gazette is a member of TLDP... -- Heather
Date: Mon, 4 Apr 2005 15:02:12 +0000 (UTC) From: Machtelt Garrels <address_elided>
Can somebody look into this? It never happened to me... Please confirm if this is fake or not.
Date: Mon, 28 Mar 2005 16:57:59 -0800 From: Brian Wildasinn <address_elided>
URGENT NOTICE: Trojan LG TLDP archives alert!
On March 25, 2005, I download some files from TLDP. My download script shows a time stamp of 9:10PM, which downloaded the entire ftpfiles directory at linuxgazette from my home LAN at 188.8.131.52.
I have a WinXP notebook attached to a wireless access point. After downloading some Linux Gazette tarballs from http://linuxgazette.net/ftpfiles, my security scanners show an active suspicious port open. I could telnet into port 5400 on WinXP from my FreeBSD box over my LAN.
Using NMAP security scan on FreeBSD `nmap -sS -P0 <wireless access point w/WEP encryption/router MN-700>` showed port 5400 open, which is described as "5400/tcp excerpt Excerpt Search" or Bladerunner Trogan.
Here is the results of ClamWin from my infect notebook:
See attached ClamWin.infection-log.txt
Date: Mon, 4 Apr 2005 10:27:01 -0700 From: Rick Moen <address_elided>
Quoting Machtelt Garrels:
Can somebody look into this? It never happened to me...
Please confirm if this is fake or not.
What you have there is a pair of false positives. I'm not sure what in Linux Gazette issue 86 Clamwin thought was an instance of "Exploit.IFrame.Gen", which I gather is an MS-Outlook exploit. The Gazette has a feature near the end of many issues where the text of particularly hilarious spam and/or virus mail is published and mocked, so that might well be it.
I would guess that the "HTML.Phishing.Bank-1" Clamwin thought it found, I'd guess it was (likewise) erroneously triggering on the "Spam Cuteness" item in Jimmy O'Regan's "Linux Launderette" column.
Brian, there's nothing wrong with paying close attention to your anti-virus software if you're on MS-Windows, but you'll want to read the results with at least a little skepticism: For one thing, given that the Linux Gazette files are a magazine, and that you read the contents rather than executing it as a program, it's unclear to me how -- even if every issue were packed chock-a-block with MS-Windows worms, trojans, viruses, and exploits -- those could have been anything but inert curios.
You may indeed have an alarmingly open "port 5400" on your MS-Windows XP box, of course -- for entirely independent reasons. Good luck with that.