Slashdot Mirror

I liked this: "There Ain't No Such Thing As Plain Text. If you have a string, in memory, in a file, or in an email message, you have to know what encoding it is in or you cannot interpret it or display it to users correctly."

My Unicode mantra is:

"You can't do random access on strings. No, not even if you turn it into UCS-2. Or UCS-4. Yes, Java is lying to you."

This is because a Unicode printable thing can span multiple bytes and multiple code points. You can't find the nth character in a string, firstly because Unicode doesn't really have such a concept as a character, and secondly because you don't know where it is. This Java code:

char c = s.charAt(4);

...doesn't do what people think it does --- it returns the 4th UTF-16 sequence thingamajig that may actually contain only part of a code point, and that code point may actually only contain part of a glyph, and trying to string slice without first checking you're at the end of a glyph is going to cause people from countries that use combining characters to hate you, because your app will break.

So in essence, in order to manipulate strings, you need to step through them from one glyph to the next, each of which may occupy an arbitrary number of bytes. So you might as well use UTF-8.

A while back I wrote a word processor using this technique: WordGrinder. It worked surprisingly well; the whole thing is 6300 lines of code and the first version took a month to write. I'll admit that I chickened out with RTL and entry and display of combining characters, but the text storage core can cope with them just fine.

But it does require a rather different philosophy for managing text than in the good old ASCII days, which is a pain in the arse sometimes...

The system used in the roguelike Linley's Dungeon Crawl (and its currently-maintained fork, Stone Soup) mostly takes care of that: when you get XP, you also get an equal number skill points; whenever an action practices a skill, some number of points from that skill pool are transferred into the skill, and eventually the skill levels up. If the pool is empty, you don't gain skill. (Also, in the skill screen, skills can be set to not be actively practiced, which greatly reduces the skill points consumed by using them; this is for things like if you're using a given type of weapon but don't plan on specializing in it.)

In practice, there's still some incidence of "victory dancing" --- after a big kill, standing around repeatedly casting some spell to make sure that the points go into some particular magic skill(s) --- but not much, and because the points would have gone into something useful anyway, it's more a question of whether the player actually wants to do that kind of powergaming.

http://xmlvm.sf.net/

GPSmid is a (not so nice yet) open source J2ME app for navigation. It wants to do all the dedicated boys do and seems to be making good progress. Disadvantages: hard or impossible to load big maps; openstreetmap is not perfect (yet); lots of features but also unfinished functionality.

If you show the app it is hard for people to belie it is J2ME and runs only in the phone.

gpsmid home page

amazing how a little "children can actually use" and "all slashdot readers" juxtaposition can lead an insightful comment to +5 funny. you know, a little mixed bag wouldn't have hurt (I just ran out of mod points).

The way I see it, we are in a good disposition to try and judge the technology. Readers of /. should try it out. It has other potential uses as well. I have already been using Ubuntu in this fashion for about 6 months now. It is absolutely phenomenal. And if you will indulge some self-promotion - http://slaps.sf.net/ is what I use this thing to boot (aside from occassional regular docs). I have a work environment almost exclusively windows, and now I have a means to use my home-brew software to dramatically cut costs.

This guy is one of the authors of ZSNES and since it can use all those shiny wrappers he talked about, just playing a game and roughly measuring the time between a defined action on-screen and the corresponding sound event is probably already sufficient. Add some perception of crackling and stuff and youll get the list he was talking about. By the way: This latency issue is very application-specific. For example, Mednafen has much better latency with ALSA than with OSS.

Sounds like this would be great for the end user. All live recordings would be reduced to free because here is the current value: http://www.archive.org/details/etree . Most all software would be free because of http://www.gnu.org/ and http://kernel.org/ , and http://sf.net/ .

Basically, everything will asymptote to $0.00, and any percentage of that is also $0.00. I doubt the lawmakers thought of it that way, now did they?

A 7 stone handicap is still HUGE. I've beaten a professional (Kano 7d) with that handicap. Sure, but it certainly puts to rest your boast: There isn't a go program running on anything that I can't give a 9 stone handicap to and crush almost without thinking - and I'm only 2k. The day a computer beats a pro seems to be far in the distant future. So, not only has a computer already beaten a pro, but the pro was actually one of the top at the game, having won a major tournament. Care to wager about beating that program giving it a 9-stone handi yourself? Come on, you said that you could crush any go program running "almost without thinking" with that handicap. Go may be complex, and the complexities of strategic thinking are really hard (including even the most basic "big" vs. "vital" concepts), but clearly Go computer programs have gotten way beyond where you thought they were. At this point, it seems like there are at least some programs that outpace your expectations. It is entirely conceivable that Go programs could be good enough in a mid term time frame that they give stones to all but the Dans & pros. Regards.

I downloaded the latest publicly available version of MoGo (release 3) and I have to say I was fairly impressed. The program beat me a couple of times at a 9 stone handicap but now I can beat it. Here is the first game I played. This is the first game I won. The trouble is that go-playing programs make a systemic pattern of mistakes that's readily apparent after playing a few times. Mogo seems to have a much better "concept" of eyeshape than other programs I've played. Its main overall strategy seems to be to play in a different part of the board (tenuki) when it can't read the local situation, which is actually a valid strategy (used by human players) so long as it doesn't neglect critical situations.

I was really impressed with the way the program uses your time to analyse the position (--pondering flag) and that it resigns when it sees the game as hopeless, although it did resign a game that it had won. The program also keeps track of the time and adjusts its analysis correspondingly, which I've never seen a program do before. Still, there is a loooong way to go.

FYI, the program I downloaded is the 64-bit precompiled linux version running on a 2.2 GHz dual-core AMD under the current Gentoo release, using the GoGui front end. The program was invoked with the options --19 --totalTime 600 --nbThreads 2 --pondering 1

one of its selling points is that it is cheap. Part of that low price comes from less-than-great quality components. But really, I wish they'd produce a software compatible high-end version too. Developing on the gp2x is very fun and easy. I ported gojo to it.

There are Berkeley sockets which are relatively portable, and then there are extremely platform-specific APIs for high performance and scalability. The old API might have run it's course, but most of the new ones are still relevant. Things like asio are helping to merge all the differences into one nice API.

Yeah, thank god for Exult. Never will we have to deal with config.sys tweaking (or the U7 engine's bugginess) ever again.

...included a BSD-licensed open source utility I worked on - PMD. I recall getting some nice emails and phone calls from them saying they were packaging it up, and they sent in some bugfixes and new rules and whatnot. They bought a couple of copies of my PMD book, too, which was nice.

Generally, I thought they were a good example of how a software company could bundle up and enhance open source software, contribute back, and still turn a profit. Selling that part of the business for $58M, sounds like it worked out OK for them...

I just with GNU Win32 had a better installer.

GetGnuWin32 is okay, but not the best. For starters, it doesn't keep track of what is installed - it just grabs the latest and extracts it to a directory; nor does it register anything as being installed.

They really need an installer like KDE4 for Windows has - with updates, and all. It'd be so much easier to update the software then.

But the great thing is that there are umpteen different ways to use most of that free software in open-source operating systems. Virtualization is probably the most reliable, but the progress in Wine has been astounding and it works great for running VirtualDub, and can use Windows video encoders like the XviD binaries for Windows. And I've been watching online television from CTV in Firefox using the Silverlight plugin, so that is a testament to progress in Mono.

In early MacPaint successor FullPaint by Ann Arbor Softworks, back in those days of single bit graphics, clicking command-L applied one iteration of John Horton Conway's Game of Life to the current selection rectangle.

Trying it idly one day on a screen grab that included a MacDraw ruler soon lead to the discovery that a long straight line with every 17th cell live on the next row generated a field of pulsars and I was hooked on what was effectively the study of Life in a narrow cylindrical universe.

The idea of filling space so easily soon also had me playing with agars where the early Mac's reliance on 8x8 patterns in the absence of colours largely confined my options to finding something close enough to a critical density that it would sustain interesting erosion from a single changed cell, eventually settling mostly on a pair of beacons, either in or our of phase:
11000000
11000000
00110000
00110000
00000011
00000001
00001000
00001100

I've resumed playing around with these every time I've found a better tool. That experience informs my strong position on disagreements over the border of order-edge of chaos and has very much informed my last few months' work with the much more productive tool of Golly 2.0 running the Generations 345/3/6 rule which Mirek Wojtowicz christened "LivingOnTheEdge" in 2001 and commented only: "In this very chaotic rule it's hard to tell if patterns will survive or die out." It may have been neglected for seven years but I'm making up for that now, and still discovering something unexpected emerging more days than not.

American English or British English?

Ha! I'm from the UK, so I use - of course - British English. However, occasionally there is a need to compromise. When I wrote colordiff I decided to use US-style 'color' in the project name (since colorgcc, colormake and other utilities already existed and I felt that made more sense) but to use UK-style 'colour' in all the documentation.

... And think of all the bytes you saved!

American English or British English?

Ha! I'm from the UK, so I use - of course - British English. However, occasionally there is a need to compromise. When I wrote colordiff I decided to use US-style 'color' in the project name (since colorgcc, colormake and other utilities already existed and I felt that made more sense) but to use UK-style 'colour' in all the documentation.

Since nobody's mentioned it yet:

More recent versions of Red Hat come with EDAC (formerly known as bluesmoke) enabled and will throw parity errors to the syslog ...

http://bluesmoke.sf.net/
http://buttersideup.com/edacwiki/Main_Page

Its predecessor, Linux-ECC, also has a plug by DJB for its use with some decent details:

http://cr.yp.to/hardware/ecc.html
http://www.anime.net/~goemon/linux-ecc/

along came windows and blew that out-of-the water - but not in ways that you might anticipate. what really blew everything away was the use of MSRPC aka DCE/RPC with some small but highly strategic enhancements.

Wow!!! OMG I can't believe I missed this!!! I've been living in the past and didn't even know it. I'm going to say it three times just so I don't forget: MSRPC, MSRPC, MSRPC is the future!

this was so successfully deployed in Windows NT that nobody really even knows that it exists. even the _internal_ teams inside microsoft often assume that an API is "direct" instead of networked, resulting in 2nd level APIs that repeatedly send 10mb of unintialised _crap_ over-the-wire.

This seems like a relatively minor problem, though. In these days of gigabit ethernet, who cares whether every function call comes with a 10MB network overhead?

all of these have varying degrees of sophistication _well_ beyond "pipes and text file formats" that have developers throwing up their arms either in horror or to scratch their heads.

I know what you mean--that pipe character is spooky. It almost looks like a tiny axe-murderer, only without arms (which is even scarier, if you think about it).

and it's exactly the ignorance and the lack of appreciation for these powerful technologies that leaves you, cthonicdaemon, in the situation that you are presently in.

With a dusty debugging skills? ;-)

there is a lost art involving inter-program communication which has not really been kept up-to-date as the complexity of applications and users' expectations both increase.

the "simple" principle which you are referring to - of joining (pipelining) applications together to achieve a purpose - was the ethos behind unix that made it so successful.

but - that principle was based on text files.

along came windows and blew that out-of-the water - but not in ways that you might anticipate. what really blew everything away was the use of MSRPC aka DCE/RPC with some small but highly strategic enhancements.

the use of MSRPC in Windows NT took the inter-process communication principle to unprecedented (as far as users were concerned) levels of transparent program boundaries.

the basis of DCE/RPC is that instead of burdening the developer with "rolling their own inter-program file communication", the developer can instead subdivide the application at the API level.

this was so successfully deployed in Windows NT that nobody really even knows that it exists. even the _internal_ teams inside microsoft often assume that an API is "direct" instead of networked, resulting in 2nd level APIs that repeatedly send 10mb of unintialised _crap_ over-the-wire.

then, later on, once the proprietary push of DCOM onto the world failed, microsoft tried again with CLR. CLR has been slightly more successful, as it is not tied historically to the operating system.

the bottom line is that there is plenty of technology out there for cross-application communication that makes it perfectly possible to have really quite sophisticated applications written in different languages.

DCOM. DCE/RPC. JSONrpc. Objective-C. CLR/.NET. even CORBA, god help us.

all of these have varying degrees of sophistication _well_ beyond "pipes and text file formats" that have developers throwing up their arms either in horror or to scratch their heads.

and it's exactly the ignorance and the lack of appreciation for these powerful technologies that leaves you, cthonicdaemon, in the situation that you are presently in.

Happens all the time, just browse a bunch of SF.net projects' homepages. Development always has a cost, regardless of the retail price of the product. This also applies to FOSS.

Well, I used to run my home server on an NSLU2 with 500GB of USB disk, before the power supply packed in. This was my main world-facing machine, and did routing, firewalling, HTTP serving for my website, NFS/SMB internally, SMTP and IMAP, backups, etc.

32MB is not quite enough for this. Picking the right software helps a lot --- spamassassin no, spamprobe yes; apache no, thttpd yes. The biggest load was processing spam; adding a greylister wot I wrote myself helped enormously, as most spam now got rejected before transfer and before the enormously expensive Bayesian filtering stage. But even so, logging into it and working remotely was deeply frustrating as every time it processed an SMTP message the session would freeze; and unison/rsync/rsnapshot (my favourite file transfer and backup system) basically didn't work, as it would just sit and swap continuously until you nuked the process.

So this little box, which runs at 4.5 times the speed anyway and has scads of RAM, looks ideal to me. Right now my server is a PC of about the same spec, and it's a huge, loud, power-hungry monster. The whole stack, which includes an ADSL router, a WRT54GL, and two hard drives, is currently sucking down 90W!

So one of these gadgets, with a home-made SSD (4x16GB USB sticks and RAID. Half the price of a real SSD. Slower, but a low-end server won't care) and an external drive that only spins up on demand, would be cheap, small, and low power and silent...

Incidentally, by the looks of it the Sheeva SOC this thing uses does not have an FPU. Common on ARMs, but a bit of a shame, as the new ARM VFP FPU system kicks arse.

One thing that gets Exchange into small businesses is that Windows SBS (Small Business Server) includes Exchange and SharePoint.

I do some volunteer IT support work at a private school. We run SBS for the office with about 12 users. We got a good deal on a new Dell server for about $500 including software. That gave us 5 client licenses (CALs). We spent close to $1000 for 10 more so for about $1500 we got a server that satisfies our needs well. Exchange and Outlook Web Access have never missed a beat. Each CAL includes the latest desktop Outlook even if the desktop doesn't have Office. Exchange, on the end of a DSL line, is the MX for the domain. ASSP sits in front of it as spam filter. With email forwarding to a $8 per month hosting service we provide offsite users with a mailbox @ the domain without using extra CALs.

Maybe we could have gone OSS and saved some money but they had Exchange on an old server and everyone was hooked on Outlook before I got involved so it wouldn't have been an easy move. Shared calendars, task reminders etc are heavily used via both Outlook desktop and OWA.

(2) GnuPlot Plots all that beautiful data....

The data may be beautiful, but the gnuplot plot won't. Use Matplotlib http://matplotlib.sf.net/ for that.

Well, here's the problem, as I see it. The command line is an expressive interface, but largely limited to character-cell based interfaces. I just think we need to get out of that mode of thought. If you can take the command line out of simple character cells, that would make it even *more* expressive.

(Disclaimer: I wrote a console-based terminal emulator to bring BBS-era convenience to the Linux console. Works pretty well, and can be very convenient at times.)

I think the issue is that the character-cell metaphor is a "good enough" interface for mouse-less work, especially with ncurses encapsulating 30 years of text terminals development. You can still add mouse and go (T)IMP too: see the OSS port of Turbo Vision. This metaphor also works over the simplest available two-way links ala ssh/telnet/serial port/etc. Once you break out of the character-cell metaphor, you've got the full X11 GUI that works over network too. The question is why would you seek any kind of intermediate ground when both metaphors already work OK?

My personal opinion is that the next great interface revolution won't occur until either a) voice commands become the norm, or b) we can project a HUD-like screen over our real sight (total immersion / augmented reality). I suspect B will happen first, and it will probably come in a form like the Nintendo WII where multiple 3D pointers are used.

Well, here's the problem, as I see it. The command line is an expressive interface, but largely limited to character-cell based interfaces. I just think we need to get out of that mode of thought. If you can take the command line out of simple character cells, that would make it even *more* expressive.

(Disclaimer: I wrote a console-based terminal emulator to bring BBS-era convenience to the Linux console. Works pretty well, and can be very convenient at times.)

I think the issue is that the character-cell metaphor is a "good enough" interface for mouse-less work, especially with ncurses encapsulating 30 years of text terminals development. You can still add mouse and go (T)IMP too: see the OSS port of Turbo Vision. This metaphor also works over the simplest available two-way links ala ssh/telnet/serial port/etc. Once you break out of the character-cell metaphor, you've got the full X11 GUI that works over network too. The question is why would you seek any kind of intermediate ground when both metaphors already work OK?

My personal opinion is that the next great interface revolution won't occur until either a) voice commands become the norm, or b) we can project a HUD-like screen over our real sight (total immersion / augmented reality). I suspect B will happen first, and it will probably come in a form like the Nintendo WII where multiple 3D pointers are used.

4. Audacity I have at least heard of, but never used. XMMS and the multitude of others mean that it is hardly a barrier.

I think you're confusing audacity with audacious. Audacity is a sound file editor, XMMS and audacious are sound file players.

I knew I'd find you here! I've seen your arse on Slashdot before.

2. Microsoft doesn't ignore the customer. They just have a lot of customers that don't care about security. Look at how many people complained about Vista's UAC dialogs, when, my Linux box has had the same thing for quite some time.

That's because sudo is a much more elegant (and less obtrusive) method of privilege escalation than UAC is. Happily, MS is remedying this somewhat with 7, although I would much rather that they just bought suDown and ditched UAC.

I'm afraid you'll probably have to wait until some enterprising 3rd party to grab the source and build some of the technology into a different product.

Don't be afraid anymore - this was actually the plan of the semantic desktop all the time. For instance, a product of the project is http://aperture.sf.net/ which is built-in into http://eclipse.org/SMILA at the moment.

Also, Ansgar Bernardi (the project lead who was interviewed in the TR article) says:

A spinoff company is also in the works...

well, I really hope this spinnoff company works out! ;-)

I've wasted more than enough time with this recently: Java risk: http://domination.sf.net. The implementation seems to be pretty good, it has some basic AI players, and can be played over a network. Good, classic strategy game, without the overhead of sorting out all the little army pieces. -- Paul

http://metpx.sf.net/

Each channel on which messages are received is a process. The receiving process decides what tasks need to be done, and "queues" (hard links the message into an input directory) it for downstream actions. This operation is daisy chained as needed. Each "queue" reader is a separate process. We run with a few dozen receivers, a few hundred senders, and half a dozen filters. so a single application with a few hundred tasks, that scales as we add load (additional load is additional senders or receivers.)

each process is just a normal python program, individually quite simple. It's multi-core ready, and dead simple. Testing of smaller programs is easier too. Parallelism is not a problem, it makes life easier, provided you approach it properly.

i'm sorry - that didn't occur to me. it certainly didn't occur to me that a project that has only not had any postings about it for only three months to be "dead".

plus, the fact that the code exists _at all_ - and is preserved - makes it possible to retrieve and revive it.

_plus_, if it does the purpose for which it is designed (look at http://htmltmpl.sf.net/ for an example), it doesn't _need_ further work; it doesn't need further "development" - it just "works".

sadly, though, gittorrent isn't _quite_ finished.
*shrugs*

Javascripts vary in quality, but the latest ones are pretty fast: for example, Javascript V8 (the Javascript from Google's Chrome browser project) is nearly as fast as Lua, which is the fastest widely used scripting language at the moment.

You might be interested in my project Clue, which is fairly similar to the Adobe project --- it compiles ANSI C into dynamic programming languages. The current released version does Lua, Javascript and Perl5; the version in SVN also does C and has a half-finished Common Lisp backend as well (code generator is done, but the contributor didn't include a libc).

I'm seeing speeds of about 1/5 of native with LuaJIT. Javascript via V8 is a bit slower. Unaccelerated SpiderMonkey produces about 1/100, and Perl5 is appalling 1/500 of native. Unfortunately, most dynamic languages don't support GOTO, which given Clue's fairly naive code generation spoils performance. (The Javascript backend has to emit a big switch statement in a loop for every function to handle control flowing from one basic block to another.) The Lua back end does nasty bytecode patching tricks to make GOTO work, which I've had to take out of the SVN version because it was just too horrible. Eventually I need to implement some sort of basic block graph reforming system to try and reduce the number of GOTOs in the generated code, but it's a lot harder than it looks.

However, unlike Adobe, all this is running on stock, unmodified VMs --- instead of implementing lots of specialised VM opcodes to make things like byte memory accesses work, I'm bending the ANSI C standard as far as it'll go to make it fit the dynamic world rather better. It's all standards-compliant, but the coding environment is odd: sizeof(char) == sizeof(int) == sizeof(double) == 1; sizeof(void*) == 2. So if nothing else, it'll make a decent testing environment.

Any volunteers to do Parrot, Ruby, Python etc back ends? Better still, any compiler theory gurus who are interested in the basic block reforming code? Nah, thought not...

Look at our website and then get sources here. Project is called YATC - Yet Another Tibia Client. This is a FLOSS client using protocol of game called Tibia, mostly developed to work with OpenTibia Server. We mostly need sprites since we currently depend on the graphics from proprietary client.

Well, replacing graphics for over 8000 items, not for the faint of the heart. If you wish, hop on, but I believe you'll be scared off :)

If you have any questions feel free to send me a mail (if you can dig out my email, it's surely somewhere in the above repository), or send me a note or anything via Slashdot. I'll be happy to explain everything to you.

To my knowledge, two companies have expressed an interest in creating a sequel to Star Control II - The Ur-Quan Masters: Toys for Bob (the creators of Star Control and Star Control II; warning: site is entirely Flash) and Stardock (better known for strategy games like Galactic Civilizations).

Toys for Bob holds the copyright to Star Control II and its characters, which allowed them to open source the game (or, to be exact, a crude attempt to get the enhanced 3DO CD version to run on Windows, which has since been cleaned up and gained additional features such as network play) as The Ur-Quan Masters a few years ago (code under GPL 2 or later, content under Creative Commons Attribution-NonCommercial-ShareAlike 2.5).

The reason for dropping the name "Star Control" and using the subtitle is simple: the Star Control trademark is owned by Atari (a.k.a. Infogrames, who bought Star Control's publisher Accolade).

In other words, TFB has all the rights to make a sequel except the name (in fact, with the open sourcing, anyone could create a sequel, albeit non-commercially). However, since TFB is owned by Activision, they can't work on whatever they like (without being fired). TFB have stated on their news page that they need help convincing Activision to finance a sequel to Star Control II; they have the will, the skill and the rights to do so (albeit not the name, but that's secondary).

I was pretty gifted in mathematics when I was young, to the point I would easily win school-wide maths competitions despite not working and having skipped a grade. I never worked much on it anymore until my natural aptitudes weren't enough to keep up during high school (I must point out that I'm French and not American), and I got to college (CS) without even knowing what a complex number was or what the sigma sign represented. Then I dropped out of high school for numerous reasons, one being that I performed too poorly due to my lack of interest and investment, particularly in mathematics.

However at that time I had an idea which sounded pretty damn exciting, namely a spectrograph and spectrogram synthesiser, so I started this project and picked up C and digital signal processing, which progressively involved more and more mathematics until I would know everything about complex numbers, Fourier transforms and negative frequencies and would start scratching maddeningly long equations on sheets of paper.

Before I picked that up I thought maths were some sort of pointless intellectual masturbation that only really served mad scientists who write papers about crap like string theory, but when I found out how it relates to all that is multimedia, and even to our senses of sight and audition, it all became very alive and interesting, and the point is, with that sort of stuff you can do anything you want. You can make your own synthesiser and make music out of it, you can create your own visual effects, or you can work for a space agency's contractor and work on systems that will be sent in space, probably a handful of other stuff that could be "creative and not too nerdy". Not too sure what "not too nerdy" involves..

It's just Babylon 5 that has limited originality. http://sc2.sf.net/

From the sound of it and from looking at spectrograms of the sounds it question I can safely claim that a few things are misleading about these sounds. I have every reason to think that these sounds have been generated by spectrogram synthesis, that is they analysed the original astro-seismic signal into a spectrogram (an image which is a plot of the frequency components and their amplitude over time) and resynthesised it into a sound so that we could hear it but also so that it wouldn't be too long and boring or too short.

However here's the thing, they used a very poor spectrogram synthesis technique (disclaimer : I consider myself a specialist in spectrogram analysis and synthesis and have made a spectrogram analyser and synthesiser called the ARSS), which consists in modulating the horizontal bands of the spectrogram with sine waves of different frequency. What's worse, they used a linear frequency scale, which means that all these sine waves are separated from each other by a fixed frequency (in our case about 10 Hz), which creates a huge envelope beat at that frequency. What it means is that this "regular repeating pattern" you hear isn't "the entire star is pulsating" as the journalist claims, but rather an artifact of the synthesis technique.

Fortunately this technique, even if it produces an awful sound, conveys the original image in the sound's time-frequency plan almost intact (just as in this example, note the similarity with the sounds in the article), and therefore I can reconstruct the original images they used and resynthesise them using a better technique to obtain a more natural sound. Which I'll post as a reply to this comment.

Justin Dearing http://plane-disaster.sf.net/ MS Access and SQLite database editor.

What are you implying?

Apparently its one of Saturn's moons that they believe has crud oil. Regardless, there might be something useful to mine and if not you have a lower gravity than earth platform for launching craft to go elsewhere.

What do you expect? Have you read his sig?

Justin Dearing http://plane-disaster.sf.net/ MS Access and SQLite database editor.

;)

Emulation, emulation, emulation. Once you've got the data on to modern systems, you can run something like dosbox to emulate an actual 8088 PC (it has a mode for this), with a slow cdrom and a small hard drive. Or even bochs or similar. Compatibility is the easy part :).

A good start is to get a Catweasel floppy controller. If you connect a 3", a 3.5", a 5.25" and a 8" floppy drive to it you will be able to read almost any floppy disk there is, including C64, Amiga, CP/M, CPC, Mac, Apple II, Famicom and so on.

Then comes the bigger problem: Finding the tools to extract files from their filesystems. There are small extraction/conversion tools on the net for almost every format there is, collecting dust on long forgotten areas of FTP servers. Some of them require some slight modifications to compile on post-80s UNIX and some only run in MSDOS with full hardware access, but with some patience, DOSBox, Google and imgtool from MESS you should be able to work with most of them.

Then finally comes the biggest problem: Finding applications that can work with the actual files...

I'm eagarly awaiting for 16bit (or float) per channel. The UFRaw process and produce result in 16bit, and then they are thrown away when passed to GIMP.

Looks like this is not here yet (I'm feeling 2.6.x will do, or 2.8 tops), but they took the all-important first step, using GLEG.

If they admit and address all the other issues too, maybe 3.0 will rock. someday..

Can't we rename it to something better?

GNU Object Oriented Lightweight Image Editing Software?

Brought to you by the creator of ARSE.

What about Dungeon Crawl?

yeah... sounds like a project I lead (not in coding though) that's still sitting around and not really being used 'cept by the original coder. Like tcl with the tile extension or PyGame, Gojo is a 2d game graphics engine. It uses Lua for coding the games. Gojo itself is written in C using SDL and other cross platform libraries. We know it compiles on x86, ppc, arm (linux, windows, os X) it's fast and powerful you get access to low-level graphics stuff but don't necessarily have to mess around with the low level stuff to make anything since standard libraries are provided for common tasks like a tile system and a sprite system. The lead dev is also working on an openGL port.

Cool stuff, and yet (due somewhat to a lack of organized documentation, and inattention on my part) it's largely unheard of and unused.

If you're curious, http://gojo.sf.net./

They get different results as they now use different usage settings from Jeita to Jeita A for the measurement- this doesn't mean the old results were wrong, they just made different assumptions. So this new figure may or may not be more accurate for you.

For sure this makes clear, that different usages will yield huge differences in battery time, so in order to get some information about your own situation, you will have to create some statistics on your own with software like Ibam.

Although it's good they changed their measurement standards for the total time, one can only hope, that they will also improve their battery monitoring: Over the time batteries lose capacity and most hardware monitoring fails to adapt to this and gets inaccurate. This is why we see so many systems dropping from "20min" remaining to "0min" remaining in a matter of seconds in the end...

I got only 0.18% of 800x480's on this site. How many unique visitors make up your 11%?

BOOKS
-----

Learning Java (O'Reilly) - one of their better books in recent years, and actually kept up to date with new editions

Effective Java (Addison Wesley) - preferably the second edition, which covers generics

J2EE Design And Development (Wrox) - heavy going, but it's simply the best book on J2EE development

ANT In Action (Manning) - describes the de-facto build tool in the Java world, which can also automate things like deployment

TOOLS
-----

Checkstyle http://checkstyle.sf.net/ - a basic static analysis tool

PMD pmd.sf.net - a more advanced static analysis tool

THINGS TO AVOID
---------------

EJB - it's gotten better in version 3.0, but a lightweight framework like Spring is still a better choice for almost every project

Maven - it might be great for some Apache hosted projects, but it's caused more problems than it solves on every system I've worked on with it