Slashdot Mirror

Record the conversation and they play it into Dragon, it works but you need a good quality audio feed. I've also tinkered with Julius and although it takes a bit of set up it works in most cases but you have to tweak it a bit more than Dragon at least in terms of what I was dealing with.

What you want is dictation software. I just (last week) spent significant time looking in to this.

For open source you have two main options: CMU Sphinx and Julius/Julian. Both options are just back-ends, you'll have to write a front-end. However, it shouldn't be too hard to do that (the source for the CMU Sphinx demos show how to get input from a mic/wav file (if you've got something other than PCM you'll just need to convert it) and set up various engines.

CMU Sphinx appears to be mainly for research purposes. You can run it in a few different modes: one with a fixed grammar (for command systems, Gnome's voice control uses sphinx in this mode), one (what you'd be looking for) uses a weighted dictionary. I didn't train it to my voice (and you wont be able to train it for transcriptions) and I was getting fairly lousy recognition rates with my $20 Logitech USB Microphone. It might work better with a high quality headset, but I imagine you wont both be wearing one.

Julius/Julian lacks a good acoustic model for English. VoxForge is working on one, but it isn't anywhere near complete.

Here is a good article that sums up the current projects

How is this so hard to understand?

It's not. But nor is code that uses goto in the idiom that FourthAge posted above.

My objection to that code is that if you do even just three or four allocations, you start getting very large indentations pretty fast, especially if you like 8-character indentations. (They get pretty long even with 4, which is what I like!) This causes a problem if you restrict yourself to 80-columns.

Arguably this is a problem with restricting yourself to 80 columns, but that's not entirely unreasonable even if I'd rather the limit be ~100. But guess how many your code uses? Your longest line is 109, longer even than my longer preference. Even if you use 4-character indentations, your longest line is still 80 characters.

If you reformat your code to use 8-character indentations and 80-character column limits, your code would become a bit uglier as you'd have to wrap four lines (a couple of which don't really have a good breaking point), and hence a little harder to understand on its face.

By contrast, the original code fits entirely within 80 characters (admittedly only just) without anything remotely like an awkward line break.

Further, in some sense it doesn't entirely follow the flow of the code. Perhaps this is a vice and not a virtue, but I tend to think of places where there's an unusual condition (like a failed allocation) as not on the same "level" as normal control flow. In this sense, I would think of that procedure as basically linear "with some provisions for exceptional conditions". In that sense, your proposal of the cascaded ifs doesn't really match my mental model of how the code behaves -- the indentation of the normal code changes depending on how many exceptional conditions might arise, and there's not really any reason why it should by that model. By contrast, the original code matches it.

(Incidentally, "linear with some provisions for exceptional conditions" is basically how I'd write it either in a language that supports exceptions or a language that has RAII. In the former case, there's a decent chance do just one try block for the body of the function, and in the associated catch test to see if each item is allocated in turn. (This doesn't match the structure of the real code exactly, but it's closer to it than it is to your nested-if code.) In the latter case, you'd have basically the real kernel code except that the deallocation would be in the RAII objects' destructors. Again, no nested ifs.)

How is this so hard to understand?

It's not. But nor is code that uses goto in the idiom that FourthAge posted above.

My objection to that code is that if you do even just three or four allocations, you start getting very large indentations pretty fast, especially if you like 8-character indentations. (They get pretty long even with 4, which is what I like!) This causes a problem if you restrict yourself to 80-columns.

Arguably this is a problem with restricting yourself to 80 columns, but that's not entirely unreasonable even if I'd rather the limit be ~100. But guess how many your code uses? Your longest line is 109, longer even than my longer preference. Even if you use 4-character indentations, your longest line is still 80 characters.

If you reformat your code to use 8-character indentations and 80-character column limits, your code would become a bit uglier as you'd have to wrap four lines (a couple of which don't really have a good breaking point), and hence a little harder to understand on its face.

By contrast, the original code fits entirely within 80 characters (admittedly only just) without anything remotely like an awkward line break.

Further, in some sense it doesn't entirely follow the flow of the code. Perhaps this is a vice and not a virtue, but I tend to think of places where there's an unusual condition (like a failed allocation) as not on the same "level" as normal control flow. In this sense, I would think of that procedure as basically linear "with some provisions for exceptional conditions". In that sense, your proposal of the cascaded ifs doesn't really match my mental model of how the code behaves -- the indentation of the normal code changes depending on how many exceptional conditions might arise, and there's not really any reason why it should by that model. By contrast, the original code matches it.

(Incidentally, "linear with some provisions for exceptional conditions" is basically how I'd write it either in a language that supports exceptions or a language that has RAII. In the former case, there's a decent chance do just one try block for the body of the function, and in the associated catch test to see if each item is allocated in turn. (This doesn't match the structure of the real code exactly, but it's closer to it than it is to your nested-if code.) In the latter case, you'd have basically the real kernel code except that the deallocation would be in the RAII objects' destructors. Again, no nested ifs.)

Hardly pedantic or lunacy. For example, pick one of the drivers from the Linux kernel, e.g. this one. Look in particular at the "geode_aes_probe" function.

The structure looks like a pyramid. On one side is the setup phase, on the other side is the cleardown phase. If one of the setup operations fails, then the "goto" jumps to the appropriate cleardown operation and continues from there. If the top of the pyramid is reached, then return #1 (success) is used. Otherwise, return #2 (failure) is used.

This function could be written in C without using goto. But would it be as easy to read and as easy to maintain? Doubt it. As it is, it's perfectly obvious what you would need to do in order to add a new capability to the driver. Tricks to work around "goto" would only obfuscate the functionality.

Get more RAM (cheap), and install xubuntu-desktop, boot to xfce. That's about all you can do to make it faster other than using lighter-weight tools, like using kazehakase instead of Firefox if you can get away with it, etc. (kazehakase is in the *buntu repositories)

For the case of 2ch, there are a plethora of specialized software(Japanese link) used to browse the message boards. For the occasional readers and posters on PCs, the web page interface is enough, but the more prevalent posters use the specialized software. For example, on Windows/Linux, I would use moz2ch, a plugin for Firefox/Mozilla that reads 2ch. On OSX, I would use CocoMonar, etc. These software packages have kind of obviated the massive need for a Web 2.0 style interface for 2ch.

For the case of 2ch, there are a plethora of specialized software(Japanese link) used to browse the message boards. For the occasional readers and posters on PCs, the web page interface is enough, but the more prevalent posters use the specialized software. For example, on Windows/Linux, I would use moz2ch, a plugin for Firefox/Mozilla that reads 2ch. On OSX, I would use CocoMonar, etc. These software packages have kind of obviated the massive need for a Web 2.0 style interface for 2ch.

According to the Julius blurb on the acoustic models used, there are currently just two languages available: Japanese and English.

"Since Julius itself is a language-independent decoding program, you can make a recognizer of a language if given an appropriate language model and acoustic model for the target language. The recognition accuracy largely depends on the models. "

"We currently have a sample English acoustic model trained from the WSJ database. According to the license of the database, this model *cannot* be used to develop or test products for commercialization, nor can they use it in any commercial product or for any commercial purpose. Also, the performance is not so good"

--Sounds like you'll be better off using the Japanese acoustic model for now ;)

There is one premade for japanese, and one for english, both are not that big, thought english one is lacking even more. You can write you own grammar, see http://julius.sourceforge.jp/en/grammar.html and for limited set of commands that is the best way to go

--
webmasters: personalized bookmarking scripts for your site
wp and phpbb plugin available

or create a small front end to edit them

The Synaptics touchpads used on practically all notebook computers already support multi-touch features. These just have to be appropriately configured with software.

For example, using the Xorg drivers and GTK configuration applet gsynaptics, you can set up a touchpad to do different actions based on double-tapping, triple-tapping, scrolling via linear and circular dragging, etc.

So if Apple figures out how to make an intuitive user interface out of touchpad motions, that's pretty cool, and other operating systems should be able to adopt similar features quickly!

http://kazehakase.sourceforge.jp/20031201.html

It can use almost every html rendering engine available to Linux. w3m, khtml, gecko, etc.

There is Dillo for Windows: http://dillo-win.sourceforge.jp/

Julius Speech Recognition Engine

Although Julius is only distributes with Japanese Acoustic Models, the VoxForge project is working on creating English Acoustic Models for use with Julius, and other Free and Open source Speech Recognition Engines (disclaimer: I am the VoxForge admin).

Hi,

If you think SELinux is too much/heavy for you, you might be interested in TOMOYO Linux. I'm so sure that most of you never heard of "TOMOYO Linux", so I'll explain briefly. "TOMOYO Linux is a project started and actively maintained by the Japanese SI company, NTT DATA CORPORATION to provide a Mandatory Access Controls mechanism in Linux."

In short, TOMOYO Linux is quite similar to AppArmor and has been available at SourceForge.jp under GPL license since Nov. 2005.

TOMOYO Linux Project

The project has a pleny of documentation but most of them are written in Japanese. I have some links.

• Japan Technical Jamboree12
• SourceForge.jp: Project Info - TOMOYO
• Papers

If you happen to have a chance to attend CELF Embedded Linux Conference 2007 (April 17th-19th , San Jose), you'll be able to see presentation and tutorial.

Abstract:

Linux has been adopted more and more by embedded devices. But its poor access control model raises critical security problems. Unlike PCs, it is difficult to apply security patches to embedded devices. Thus, embedded devices should be designed with due consideration for imperative access control. Linux kernel 2.6 has been equipped with LSM (Linux Security Modules, OS level security framework) to provide MAC (Mandatory Access Control, imperative access control) ability. NSA's SELinux (Security-Enhanced Linux, LSM applicant security server) provides very fine-grained access control, but its requirements for embedded devices seem to be too excessive. LIDS (Linux Intrusion Detection System), on the other hand, is relatively compact and better suits embedded systems. However its access control granularity is rather sparse. There are many limitations which are specific to embedded devices. For example, slow CPU speed, storage capacity for OS and programs, filesystem that doesn't support xattr (extended attributes), hard-links and symbolic links used for busybox (multi-call binary to save space), files dynamically created on volatile filesystem. TOMOYO Linux (http://tomoyo.sourceforge.jp/index.html.en) is yet another way to provide a lightweight and manageable MAC ability. It is available under GPL and applicable to and suitable for both PCs and embedded devices. In this session, we will present an overview of TOMOYO Linux and explain why TOMOYO Linux is suitable for embedded devices. We will also show some demonstrations.

Hi,

If you think SELinux is too much/heavy for you, you might be interested in TOMOYO Linux. I'm so sure that most of you never heard of "TOMOYO Linux", so I'll explain briefly. "TOMOYO Linux is a project started and actively maintained by the Japanese SI company, NTT DATA CORPORATION to provide a Mandatory Access Controls mechanism in Linux."

In short, TOMOYO Linux is quite similar to AppArmor and has been available at SourceForge.jp under GPL license since Nov. 2005.

TOMOYO Linux Project

The project has a pleny of documentation but most of them are written in Japanese. I have some links.

• Japan Technical Jamboree12
• SourceForge.jp: Project Info - TOMOYO
• Papers

If you happen to have a chance to attend CELF Embedded Linux Conference 2007 (April 17th-19th , San Jose), you'll be able to see presentation and tutorial.

Abstract:

Linux has been adopted more and more by embedded devices. But its poor access control model raises critical security problems. Unlike PCs, it is difficult to apply security patches to embedded devices. Thus, embedded devices should be designed with due consideration for imperative access control. Linux kernel 2.6 has been equipped with LSM (Linux Security Modules, OS level security framework) to provide MAC (Mandatory Access Control, imperative access control) ability. NSA's SELinux (Security-Enhanced Linux, LSM applicant security server) provides very fine-grained access control, but its requirements for embedded devices seem to be too excessive. LIDS (Linux Intrusion Detection System), on the other hand, is relatively compact and better suits embedded systems. However its access control granularity is rather sparse. There are many limitations which are specific to embedded devices. For example, slow CPU speed, storage capacity for OS and programs, filesystem that doesn't support xattr (extended attributes), hard-links and symbolic links used for busybox (multi-call binary to save space), files dynamically created on volatile filesystem. TOMOYO Linux (http://tomoyo.sourceforge.jp/index.html.en) is yet another way to provide a lightweight and manageable MAC ability. It is available under GPL and applicable to and suitable for both PCs and embedded devices. In this session, we will present an overview of TOMOYO Linux and explain why TOMOYO Linux is suitable for embedded devices. We will also show some demonstrations.

Hi,

If you think SELinux is too much/heavy for you, you might be interested in TOMOYO Linux. I'm so sure that most of you never heard of "TOMOYO Linux", so I'll explain briefly. "TOMOYO Linux is a project started and actively maintained by the Japanese SI company, NTT DATA CORPORATION to provide a Mandatory Access Controls mechanism in Linux."

In short, TOMOYO Linux is quite similar to AppArmor and has been available at SourceForge.jp under GPL license since Nov. 2005.

TOMOYO Linux Project

The project has a pleny of documentation but most of them are written in Japanese. I have some links.

• Japan Technical Jamboree12
• SourceForge.jp: Project Info - TOMOYO
• Papers

If you happen to have a chance to attend CELF Embedded Linux Conference 2007 (April 17th-19th , San Jose), you'll be able to see presentation and tutorial.

Abstract:

Linux has been adopted more and more by embedded devices. But its poor access control model raises critical security problems. Unlike PCs, it is difficult to apply security patches to embedded devices. Thus, embedded devices should be designed with due consideration for imperative access control. Linux kernel 2.6 has been equipped with LSM (Linux Security Modules, OS level security framework) to provide MAC (Mandatory Access Control, imperative access control) ability. NSA's SELinux (Security-Enhanced Linux, LSM applicant security server) provides very fine-grained access control, but its requirements for embedded devices seem to be too excessive. LIDS (Linux Intrusion Detection System), on the other hand, is relatively compact and better suits embedded systems. However its access control granularity is rather sparse. There are many limitations which are specific to embedded devices. For example, slow CPU speed, storage capacity for OS and programs, filesystem that doesn't support xattr (extended attributes), hard-links and symbolic links used for busybox (multi-call binary to save space), files dynamically created on volatile filesystem. TOMOYO Linux (http://tomoyo.sourceforge.jp/index.html.en) is yet another way to provide a lightweight and manageable MAC ability. It is available under GPL and applicable to and suitable for both PCs and embedded devices. In this session, we will present an overview of TOMOYO Linux and explain why TOMOYO Linux is suitable for embedded devices. We will also show some demonstrations.

Interestingly, the article confirms what I've been doing on my own IBM Thinkpad 570e lately. My only question to whomever still might be reading this is: is there a lightweight CSS-compatible browser that's not a memory pig on the order of Konqueror or even Firefox? Dillo works well enough, but I'm wondering if there isn't maybe a browser between Dillo and the heavyweights.

apt-get install kazehase should install it. (I don't know if it is in anything other than

It is lighter than the XUL (Firefox, SeaMonkey, IceApe, Iceweasel) or Gnome (Galeon, Epiphany) Gecko browsers browsers. Last time I used Kazehakase, it was fine on a 200mhz machine with 64meg ram and window maker. Skipstone was another gtk web browser, but as far as I can tell it has been dead for a while now.

Kazehakase is another Gecko-based browser to keep an eye on. Newsforge wrote an article about it back in 2005.

I currently carry Knoppix, Berry and Minimax. Berry for fun, Knoppix for work and Minimax for emergency situations.

BTW, Minimax is pretty interesting. It's a 32 megabyte live-cd/initrd image, and it has a whole lot of console tools. The best part of it is you can fit your favorite mp3s on the same disc, which means you can play music while you do data forensics. Too bad it's been discontinued.

Honestly, I thought the GTK+ Ruby stuff was half decent. And the documentation was better than when I was writing Perl-GTK+ s. http://ruby-gnome2.sourceforge.jp/

• uTorrent (BitTorrent, Windows)
• Azureus (BitTorrent, Java)
• BitTornado (BitTorrent, Windows/Linux/BSD)
• KTorrent (BitTorrent, Linux/BSD/Mac)
• eMule (eDonkey, Windows)
• aMule (eDonkey, Linux/BSD/Mac/Windows)
• FrostWire (Gnutella, Java)
• Cabos (Gnutella, Java)
• Shareaza (Gnutella2/Gnutella1/eDonkey, Windows)
• Ares (Ares, Windows)
• DC++ (DirectConnect, Windows)
• RevConnect (DirectConnect, Windows)
• Valknut (DirectConnect, Linux/BSD/Mac)

Although Japan and Russia got there a bit quicker ... Intelcom provide a encoder and decoder Java toolkit for mobile phones. Japan have a Sourceforge Java project for encoding and decoding too.

Java is already fragmented. The result of open sourcing Java will actually be consolidation, i.e. killing of competing VMs. And a huge open source test suite will greatly benefit all surviving JVMs, which is a good thing.

How can you not see this?

Javas problem is not that it might get fragmented, the problem is that it IS fragmented. Do something about it! Let Java free!

The total number of Kanji in wide use for Japanese is something closer to 2500 rather than 7000 (even Chinese only regularly uses some 3000 or so), and it appears to be necessary to know something like 1800 to 2000 characters to be able to read a typical Japanese newspaper like the Nihon Keizai Shimbun. The Japanese also make use of syllabaries known as kana, of which there are only some 40 characters, which easily fit on a normal keyboard. The way most Japanese keyboards work is they type a word in kana, which they then use an extra key to select among the possible kanji that may represent the kana. It is also possible to type Japanese text using a normal US keyboard, using what are known as input methods. I use anthy to do this, and basically you type a romanized version of the word you want, which comes out as kana, and you can then use the spacebar to select among the possible kanji.

Sort of... not totally stand-alone in the traditional binary executable sense. You still need the Ruby interpreter.

But several tools (Ruby2EXE, ExeRb) allow you to bundle your program, libraries, and the Ruby interpreter into an executable that you can then distribute. I've used them in the past and they work well -- never had any users tell me they couldn't install the program.

There are various options available for a GUI. I've used wxRuby a lot. It's an interface to the WxWindows/WxWidgets toolkit. I think it works very well, and I really like it's auto-layout features using sizers, although the API is very C++-like.

Another toolkit that people use a bunch is fxruby, which interfaces with the Fox toolkit.

There are lots more GUIs. Take a look at the Ruby App Archive or lurk on the mailing lists to see what toolkits people are using (or just ask them).

They tried to outdo Firefox tab browsing with a feature call Quick tab which shows thumbnail view of all open tabs in a single window.

You are very much correct.

Also, RoR's ORM does not play nicely with stored procedures. Bring this up to any die-hard Rails fanatic and they will start spinning: "You don't need it! Stored procedures are satanic and force business logic into the data store."

Which makes me think that most RoR pushers don't have experience with large corporate DBs.

A nasty side effect of RoRs current popularity is that it completely overshadows some very good Ruby web frameworks such as IOWA and Amrita

My employer used an modified (in house) version of CCUnit to automate testing on Solaris. For Windows testing, we used WinRunner. But that was two years ago. CCUnit claims to be platform dependent, so it might work on Windows.

Actually, on this linux box (Ubuntu, using Gnome) I have Kazehakase set as my default browser...mostly because it loads far faster than either of them--less than one second to open even when not cached. It's Gecko based and uses Gtk, so integrates well with my system (also nice when using Xfce on less powerful systems).

It's easy to set up to keep a searchable full-text history (with thumbnails), plus has a few features Firefox lacks without extensions...session saving, toggle between multiple proxies and mouse gestures to name a few. Its zoom enlarges images like Opera's does, unlike Firefox's which just does text. It is a bit unpolished still, however, but it's a neat project:

http://kazehakase.sourceforge.jp/

http://dillo-win.sourceforge.jp/index.en.html is the site, and http://sourceforge.jp/projects/dillo-win is the project page.

Last update was in 2003.

I'm also e-mailing this post to you.

http://dillo-win.sourceforge.jp/index.en.html is the site, and http://sourceforge.jp/projects/dillo-win is the project page.

Last update was in 2003.

I'm also e-mailing this post to you.

Have a look at the WxRuby homepage. I've used this before for coding up a frontend for a Ruby game and it has worked very well for me. I was also able to package it up into one binary via RubyScript2Exe and ExeRb which was important for me.

[ tons of tips and ideas what's possible with a Z follow ]

The 5500 and others are more like little Linux laptops then PDAs. While I am far from a typical PDA user, the absolutely INCREDIBLE stuff I can do with just a 5500 and a wireless card continues to astound me today. To be fair, I never bought a Zaurus with the intention of ever doing typical PDA like stuff, but just wanted an easy familiar environment to hack in.

Years ago I had a USR P1000 (The Palm 1000, before Palm bought it from US Robotics), and while it was a great PDA (for the day), it was underpowered for what I wanted and most importantly LACKED A KEYBOARD, which makes all the difference in the world. One day I worked an ENTIRE day with only my P1000, a ssh client and a (9600 baud) serial link to my cell phone to see just how doable it was. As a unix admin doing security work the P1000 did have SOME uses (serial console to Sun boxes, ssh client for accessing mail via Mutt, etc) but the end result was a less than productive day overall. Trying to edit files on unix boxes with vi using Graffiti was quite painful and I vowed I'd never buy another PDA until it had at least a minimal keyboard to work with.

Fast forward to my (now several years old) 5500. Shortly after getting it I wiped the original Sharp rom and replace it with the actively developed OpenZaurus distribution, and was very happy with the results.

I have a very portable linux box with wireless, nearly all the software I was using on Solaris and Linux, as well as the pretty Qtopia apps and a half-way decent environment. I've been able to get nice tools like nmap, p0f (Passive OS Fingerprinter), Kismet, and other excellent unix based tools working with minimal effort on the Z under OpenZaurus (and the a lesser extent the Sharp ROM). Under OZ I can compile and run MANY common exploit tools like the awesome Metasploit framework, which require perl, and to a less extent Python. Both are no big deal to get going on the Z, especially since the Z is binary compatible with the IPAQ based Familiar distribution, and usually just needs the odd library to get an app working. That's all fine for text based apps, but since OZ (using Opie, at least) is QT and not X based, a variety of GUI based apps don't easily run. There ARE solutions to getting X based apps to run with minimal fuss, including the original x11zaurus package, and more recently the excellent X/QT package, as well as simply running one of the versions of the vncserver for Zaurus which of course allows you to display X not only on your Z, but also on any other VNC compatible device (such such as you cell phone, Linux, Windows, etc).

More recently the GPE environment and projects has become available, and is offers an attractive alternative to Opie, but with X11 compatibility built in.

For me, I joined the Debian religion ~5-6 years ago after experimenting to see what all the fuss on /. was all about. It didn't take long before I was the typical Debian crack addict apt-getting any application I wanted to check out on a whim. After living in Ottawa for years I was very well aware of the Corel (and later Rebel.com (who themselves were called Hardware Canada previously, and were a unix reseller) Netwinder , which was a cool little ARM based PC, which unfortunately suffered under the idiocy of Corel's managem

So how is this different to the GTK/Gnome bindings for Ruby that have been out for years?

Personally, I'd love to see Ruby used as the next-gen language for Free Software application development. It rocks!

Maybe you should get a internet connection.

http://slashdot.jp/

http://sourceforge.jp/

Maybe japanese don't like americans to host their projects.

Ah... I'll better stop... or I'll get modded as Troll...

echo 'print "hello world\n"' >hello.rb

echo '#!/usr/bin/ruby' > hello.rb
echo 'print "hello world\n"' >> hello.rb

So did I win this dick-shrinkage competition? (-:

Do you know QCad II ?
QCad II will use Scripting / Plugins, " Python ".More...
And...
Other GPL CAD/CAM software SagCAD "can" use " Ruby ".