> Is dictation really the most common or most useful application of speech to text?
Definitely not..
> If you are using it for dictation then a long training period is acceptable.
Well, depends on 'long'. For most practical uses, peopel seem to find 3+ hours of training for it to be too much, unless they have a very direct purpose for entering text without needign their hands.
> But I find voice recognition in use much more often in phone IVR systems. When I call up my power company it asks me to say my account number. When I call a major hotel chain it asks which property I want info about and connects me appropriately. I saw a demo from IBM several years ago where they were doing money management and the system was recognizing mutual fund names. Movie theatre listings, 411, and the list could go on.
The complexity of speech recognition depends ALOT (to put it very mildly) on how big the vocabulary is that you are usign, and how many similar sounding words it contains.
All the things you list would be relatively simple, and won't require much if any training because they can rely on distinctive words froma small vocabulary.
This could be done with general purpose computing hardware like a decade ago, and was first demonstrated by IBM in the late 60s.
It is seriously different from what is required for generic speech to text for situations where you have no clue whatsoever what a user might be going to say.
To give you some exampels of the problems generic speech to text translation runs into:
Did you just say to? too? two?
It is only possible to tell if you have the context for it. In generic speech to text, that is a lot more difficult then when you are listening for very specific words and have determined the context beforehand.
> Not only are these things that are probably a lot more commonly used than dictation, but they are also the things that would save companies the most money. For the price of something like Dragon Dictate most people would save money hiring some starving college kid to type up whatever it is for the frequency they need it. Being able to shut down call center locations instead of just outsourcing them to India or the prison system saves a lot more money.
No doubt but the question is how usefull this technology will prove for that. As mentioned before, there is a huge difference between listening for a list of words and doign generic speech to text.
> Will a general purpose CPU fit or operate in a phone that can be on for a week? I almost never shut off the phone and it still lasts a week, and I don't want to sacrifice that run time for speech recognition.
Good point, but with modern cpus and no need to have the speech recognition software runnign all the time, I think you can indeed have a phone with a long lastign battery, and still have a fairly powerfull cpu in there for the few moments where you really need it. For doign relatively accurate speech to text translation you need somethign faster then a p90, and I think there are mobile phones out there that manage that already.
Most of the time, a phone is left in 'standby' mode, which doesn't require much, given that you can tell the cpu to go sleep/slow down.
Don't get me wrong btw, I do see a use for the speech recognition hardware, but I'd think that use is for rather specialized devices.
> task specific silicon becomes very useful when you don't have as much space/power/heat-disipation as you want.
Definitely, and I see quite soem uses for that... People use portable recorders for dictation now.. it would be cool to have such a small handheld device that does speech to text translation instead.
10 years ago, a 486dx33 together with a specialized dsp could do it, so I bet with this new piece of silicon and some low class cpu it is also possible.
Hmm. so that is where the possible niche for this hardware is I guess.
A small sidenote regarding 3D graphics accelerators and general purpose CPUs, whle you are absolutely right regarding the huge increase of cpu power offsetting the special hardware of such cards over time, we also get a new generation of 3d graphics hardware every so often, and there is a lot of room for improvement there still. Somehow development of the old PDS hardware was stopped as soon as CPUs became capable of doing the job.
> 100 to 1000 times more efficient worth $1M? meh. maybe. > 100 to 1000 times more accurate worth $1M? definitely.
Accuracy does not have to be a problem with modern speech to text systems, but the need to 'train' them to get that accuracy, and the need to talk to it in a somewhat distinctive way, make them far less efficient.
I'd rather say that the time it takes to get used to a speech recognition system (and to get it used to you where appliable), together with the soemwhat heavy cpu requirements, are what currently stops use. To me that means that the first thign that is required is efficiency, the accuracy is already there.
(I have been using speech to text for over a decade now, starting out with another hardware solution in the first half of the 90s (IBM's VoiceType Dictation, back then called Personal Dictation System if I'm not mistaken, and even that system already had an almost as good accuracy as I manage myself)
During 1994 upto 1998 I did marketign and technical support for IBM's Voicetype Dictation products..
Initially, doing anythign beyond understanding a few words would take special hardware, but after a bit of 'training' highly acurate and fast speech to text was quite a possibility with a specially developed dsp.
Then, the pentium class cpus came about, and a p90 could just do the whole thing without the dsp.
So, now someone is developing a new dedicated piece of silicon for this.. lets see how long it takes for general purpose computers to catch up.
The issue is not that this is not usefull, but that it either has to keep developing, or offer a somewhat longer lasting price/performance ratio or much better features for a logn time to come.
Years ago I used Notes mail, cc-mail and profs on some IBM mainframe.. all were company wide 'private' mail systems that would allow selective communications with other parties (that used the same systems).
Very informative. I'd like to point out however that a situation somewhat similar to GDI may exist on Unix platforms (including Linux) as well when you happen to require dri.
> Yeah you're just making this up because you don't have an answer. What was this "slight difference", and why did you have to figure it out, eh? Come on, you challenge me to provide facts, you haven't provided a single one.
RH 2.4.22 kernel properly supported acpi while gentoo with a 2.4.22 kernel did not. RedHat imported patches from the 2.4.23 pre series.
> The Linux kernel has never been released for "marketing" reasons. Linus has never even worked for a company that markets Linux.
Linus releases things when he believes them ready, agreed there. That said, in both Linux and FreeBSD things come as they come, and the argument of 'too late' doesn't seem to make sense in either case. Maybe you should learn a bit about sarcasm here.
> That is 2 years old, and way before Linux 2.6 was released. It was close to the start of the Linux 2.5 development cycle.
The issues being discussed are still relevant, most importantly, signal delivery to threads.
> No that doesn't break all old apps that use libpthread. Why do you just claim that sort of FUD? FreeBSD 5 actually cannot pass the NPTL compliance test suite.
Hmm, you are right indeed that it doesn't break all of them, only those that rely on the old way of signal delivery.
> cdrecord dev=/dev/hda
Thanks, hadn't tried that for some time now, and on my 'modern' workstation it indeed works with the 'atapi' support only (it had failed on my server without the ide-scsi 'hack'). See, providing actual arguments can be informative and makes discussing worthwhile.
> Linux has one interface. It is accessable through ifconfig, ip, etc. It has a number of layers (sockets, tcp, ip, ethernet, tunnels, etc). If FreeBSD didn't have the same layers it would be useless. Tell me what you you mean by Linux having a zillion layers.
Sorry, that was bad wordign on my side. Should have said, has a zillion similar implementations of the interface.
> apt-get install pppoe
So I do have to install an external package for it. That is not goign to be very helpfull really when for example doing a network install over a dsl connection.
> how you connect this to the fact that the french are the laziest pieces of shit in Europe, I have no idea. Ingrateful, lothesome, delusional, meritless waste would be a good word for the french. THey want to drag the rest of Europe down to their level. Otherwise they would be forced to match the level of industry exemplified by the Germans, the Italians, the English, and the Spaniards.
Last time I checked, most industry in Brittain is gone (they trade, but don't produce that much), Germany has economic trouble beyond belief, Spain is not doing that well really either and nor is Italy. Only the UK is doign relatively well from all the examples you gave, and they are not similar in how their economy works.
> God forbid that happen to the race that considers multilingual signs to be an insult to their culture.
While I agree with the udnerlying sentiment (French being absurd with regards to protectign their own culture) your statement is factually untrue, and could apply as easily to the USA.
Fact is that the French require products sold in their country to INCLUDE texct in French (besides any other languages).
You may find virtually identical rules in other EU countries, this has to do with that the consumer is supposed to be able to read whatever is in a product.
A somewhat silly situation is the French requirement that any websites run by French companies must be in French (and can optionally support other languages) regardless of if they aim at a French public or not.
At any rate... quite a few Europeans tend to call France 'little America' and with good reason, you'd be surprised how well the USA and France compare when ti comes to blind nationalism, unfounded national pride and fear of anything 'foreign'.
> That isn't lack of direction, there were problems with the page scanning code and so it was replaced with a better version. Yes it was unfortunately a stable kernel series and that wasn't good at all, but the alternative was to either fix it or always have an unstable "stable" series. That doesn't say anything about lack of direction.
> As I said, this wasn't lack of direction. I suggest you look at the fiasco that is FreeBSD 5. Their operating system is *years* late, and the lack of direction splintered its developers (yes, including resignations and a fork).
> Why would that be "too many"? You've skipped the "lack of direction" question, and made this assertion. What is the problem with having different vendors offer different sets of kernel patches.
> What was the last thing you had to do differently because two vendors offered different kernel patches? How much did it cost you?
The last time was when I had to figure out why the fuck some RH 2.4.x based kernel worked slightly differently then a Gentoo one (my normal testing environment) for a for my customer relevant situation. It costed approx 2 hours to figure out where the exact difference was between 2 kernels with identical version numbers, both compiled with identical options, but not from the exact same source (redhat patches)
Supposed purpose of a 'stable' version, provide a stable version.
Reality in the Linux kernel was implementing something that was not proven and could not be considered stable yet (the vm).
I consider that lack of direction.
I don't blame the developers for not getting it right the first time around, but I do consider having this happen in what is supposedly a stable version to be a major issue.
What happened with FreeBSD 5 happened in the development release, not in something that was supposedly stable and ready for normal use.
It gets released when it is ready as opposed to when it is convenient for marketing reasons.
There will always be issues that result in controversy and disagreement. FreeBSD keeps that out of the stable releases that peopel count on, and breaking the binary interface in stable releases is not done.
Linux has not been able to keep that out of stable releases, and has had multiple cases of breaking binary interfaces in supposedly stable versions.
As for pthread support, FreeBSD 4.x lacks kerel schedulable units and can be said to not be fully pthread compliant.
With regards to Linux and FBSD and pthread support, a nice bit of dicussion can be found at http://kerneltrap.org/node/view/422 for example.
FreeBSD 5.x is as possix threading complient as it gets while Linux suffers from some small issues regarding signalling (officially fixed when usign 2.6 and the new phtread library, but that breaks all old apps that use libpthread)
> Linux kernel is fully device hotplug capable for hardware that supports it > Linux doesn't need "a zillion" layers. Linux uses SCSI for everything other than PATA controllers, which it uses a seperate IDE layer for. 2. FreeBSD also has an IDE layer.
Ah, tell me then how to get an ide cd/dvd burner to work without the 'ide-scsi' hack.
And yes, FreeBSD has an ide layer as well, but for any relevant devices this neatly plugs into the underside of CAM.
> No it doesn't
You obviously never saw how netgraph works, so I'll excuse you for not realizing the difference and not seeing how linux does in fact provide a zilion similar layers instead of one.
Tell me, how do you get pppoe to work without the rp-pppoe package? just saying it does, does not prove anything at all, and anything I can find on google as well as my own experience tell me I need that 3rd party package to get it to work.
Just in case you want to know, on a stock FreeBSD machine, you load the pppoe kernel module and it works. No compilation needed, no external packages needed, nothing of that all.
Again, calling yes/no makes for unfounded claims. Back them up or shutup. If you do not have anything to contribute in the BSD section other then proclaiming Linux superiority, without backing up your claims, then you are the troll here my friend.
> No, you implied that that actually was the case. You said words to the effect of "too many people mess things up, that applies to linux".
I refered to a well known saying. If you have too many people working on something, that does not result in better results, more likely in worse results.
That was an answer to the implication in the parent post that more people means better results by definition.
And yes, that implies that this could well be the case for Linux.
> You are a fine person to accuse me of baseless and factually wrong claims. What lack of direction in Linux?
It is a little while ago now, but I'd suggest reading up on the VM related discussions with regards to Linux for a nice example.
I'd also suggest looking at how many Linux distributions come with their own collection of kernel patches.
The later is a direct result of too many different people/organisations with different priorities.
It is also a direct cause of it beign more expensive to support for me. The only way around that is to support one single distribution only.
> As opposed to what in FreeBSD?
A single distribution, features that are claimed to be there actually work (ACLs, large file support, complete pthread support to just name some examples)
> How can it be directly linked to the people working on it?
Again, check out for example the VM situation in 2.4
> Again, back up these claims: what lack of structure, how does it link directly to the people, how is FreeBSD different?
I clearly stated that those were my personal experience. It is what applies to my situation, yours may be different.
The lack of structure was a claim independent of my experience, but for example FreeBSD gives you a clear and easy to handle source tree, including ALL tools you need to build it and all tools that depend on it. In case of Linux, I need to go collect the kernel source, binutils, filesystem utils, correct compiler etc from different places (not even talking about 'normal' userland tools here)
In case of FreeBSD those have been tested together, and produce a predictable result. You also simply do not have to put efford into ensuring you get everything in the correct versions yourself.
For as far as the kernel itself goes, I'd for example take a peek at how support for removable media and ide cd devices etc works. The same applies for non-ethernet network devices for example.
FreeBSD uses CAM for supporting anythign that can work as if it is a scsi device, instead of needing a zilion different layers depending on what physical connection the device happens to have (scsi over ide to just point you at one specific example)
FreeBSD uses netgraph for supporting any type of networking interface, providing for a structured way of defining and supporting network interfaces without having to deal with their physical properties, whereas Linux has a slightly different layer for each type of network interface (and doesn't support somewhat relevant things like PPPoE without a 3rd party tool)
It of course may have to do with lack of design capabilities but I honestly do not believe that is the case with the core Linux developers. The only alternative explanation I can see is too many people workign on similar things independently and not integrating their work properly.
Glad to see that at least you are willing to discuss and left the name calling and assumptions out. I am quite willing to discuss as well in that case.
> No you didn't. You said (maybe indirectly) that the Linux kernel was being mucked up by having too many people working on it.
I implied that that might well be possible yes.
> What I find very hilarious is that BSD zealots who are now trying to claim that Linux must be worse because it has *more* people working on it.
Lack of direction, lack of knowing what you can count on with Linux? yes, those are issues when using and supporting it, and can directly be linked to the huge diversity of people working on it and their conflicting priorities.
More people working on it also means more resources.
What works out better is not that easy to say, and depends a lot on what you need.
I do know that for me it is approx 30% cheaper to support a FreeBSD server instead of a functionally equivalent Linux setup simply because of the lack of structure in Linux (which results directly from the diversity of people working on it)
I also know that it is easier (and as a result cheaper) for me to support a linux desktop on some random piece of hardware exactly because of the same diversity.
For the rest, if your claim about 'BSD zealots' were true, that would just make it a typical case of pot and kettle.
- Look at which slashdot section this is posted in - Look at the original post I replied to.
What does it have to do there other then trying to do the exact same thing you are accusing 'BSD zealots' of?
At any rate, reply to this if you feel so inclined to having the last word, but unless you actually provide some kind of argument and back it up (as opposed to making assumptions which are based on very little and are factually wrong), I'll ignore your replies.
> Let me see... I suppose you think FreeBSD is cool and most scalable and has the best networking stack and is the fastest and most sable and second most secure (behind OpenBSD, of course) and best engineered and consistient and cool and best networking stack, and most stablest operating system evar, right?
Nope, neither do I think Linux qualifies for all those. Both systems have their merrits and disadvantages.
What I was pointing at here is that the fact that a zillion peopel are involved can be as much a disadvantage as an advantage, and as a result is a stupid argument to make.
> Nice. Linux must suck, eh?
I do commercial support on both Linux and FreeBSD, I run both for commercial and private purposes also and I maintain a small Linux distribution together with a friend (as well as maintaining my own variation on the FreeBSD distribution)
I have been using both systems since the first half of the 90s (pre 1.0 versions of linux and 2.0 beta of FreeBSD were the first versions I worked with)
I have made contributions (abeit small ones) to both systems.
I do think I have some background here. Now, what do you have to base yourself on? claims from an AC who doesn't even provide anything like an argument or background for making those claims are pretty silly.
It seems to me that when you replace FreeBSD with Linux in your post, you exactly get the opinion of zealots like you.
What I find rather hilarious is how stupid some (luckily by far not all) Linux fans respond to anything that might be remotely critical of Linux.
You may want to look in/usr/ports/sysutils/livecd for creating a nice customized 'live' cd.
You may want to check the handbook on generating releases if you want to build your own customized 'release' that can be installed from cd (or floppy or over a network etc)
Very roughly it comes down to either cd/usr/ports/sysutils/livecd; make or cd/usr/src; make release
> Also FBSD 5.3 is in debug mood which makes it slow while 4.10 is normal.
mood?:) anyway.. with the default install it is indeed. Instructions for changing this when compiling your own kernel (try it, its really simple) can be found in/usr/src/UPDATING
The debug settings in the stock 5.x kernel slow it down, but it supporting much faster ide controllers properly and making better use of resources on hyperthreadign and smp machiens can easily offset that, so you may still find the 5.3 beta to be faster then 4.10
> 4.10 has the latest utilities and apps that fbsd 5.2 lacks.
If you use the ports collection, that is definitely not true, both run approx the same set of applications in whatever version you install (the latest usually when you keep your ports collection uptodate). Also, 5.x comes with newer versions of gcc and related tools for example.
I'd say.. if you intend to try this on relatively new hardware, wait till 5.3 gets released. Otherwise, go with 4.10
In either case, ensure you install the ports collection and the cvsup package (you will eb asked about the first while selection the distributions to install, and you can get the later by answering 'yes' to the question if you want to visit the configuration panel at the end of the installation. Select packages there, and add the cvsup package)
When at the configuration panel, you should also configure X and a desktop if you intend to use this as a workstation.
Then, after install and reboot, do a cd/usr/ports/misc/instant-workstation; make install (or cd/usr/ports/misc/instant-server; make install if you are installing a server)
> Let's see....... > all employ full time staff to work just on the > Linux kernel. Apart from hundreds of other small > companies, governments, educational institutes, > thousands of volunteers.
Ever heard what too many cooks do to a potentially good dish?
Which is too bad. the similar clause in the BSD license was removed for good reasons, and without wanting to give any judgement as to the quality of Hsu's work, he obviously did not get the clue there.
> Yeah, it really pisses me off that The GIMP only works on two distros.
> FFS, get over it, man. There's no "incompatible Linux distributions". You name me THREE open source apps (exclusing the obvious installers and config tools) that only work on one distribution.
Ignoring the point is not really going to help.
Yes, I can run vrtually any opensource package on any linux distribuion and any bsd distribution.
Since each and every linux distribution comes with a slightly (or at times wildly) different set of libraries and versions of libraries, there is no guarantee that you can take a binary from distrivution x, and expect it to run without any hastle on distribution y. Yeah, you can definitely get it to work by installing extra libraries or recompiling the thing.
> Struggling? Thought so. Your talk about "incompatible distributions" is ignorant and ill-informed. 99.99999% of open source apps work on all distros without any hassle.
Did you ever build comemrcial Linux software? I did. I also did the installer. There is a good reason for most commercial software either supporting only a few distributions (officially at least) or being statically linked to most stuff they happen to depend on.
You obviously never looked at what those nice installer scripts do but you may find funny things as binary distributed software installing differently based on for example your version of gcc, glibc and a few other such things.
> ATEOTD, Linux has broader hardware support,
Possibly, especially when it comes to non x86 hardware.
I use fairly modern x86 hardware for a whole variety of purposes (including hosting and network infrastructure), and I have yet to encounter a device that I actually want to use that is not supported.
The same can be said about Linux, so no difference there as long as you keep to a supported platform of course..
> runs faster, has better SMP,
If Linux runs faster is rather debatable. My test server runs both FreeBSD current and gentoo with linux 2.6 kernel in a multiboot config. (it is a dual cpu machine btw)
Running exactly the same Apache configuration, in both cases compiled from source, results in the fbsd version handling between 5 and almost 20% more requests/time on a mix of static and dynamic (php and perl) content.
I have the same systems installed on my workstation, an adm athlon xp 2600+ with 512mb and a gforce4 mx.. When running FreeBSD 5, my favorite multiplayer fps (Enemy Territory) runs substantially better then when running Linux (somewhat interesting seeing how this is in fact a Linux binary)
Both annecdotal evidence at best, but definitely 2 cases where Linux doesn't run faster.
With regards to SMP, esp. on non x86 hardware Linux does a lot better, but then, FreeBSD doesn't run on most such hardware to begin with.
If this is true for x86 hardware is debatable, and I'd like to see what things look like once 5.x has been 'stable' for a while, and I keep an eye on dragonfly and their smp work.
I have seen some performance comparisons that were at least trying to measure things instead of basing themselves on annecdotal evidence.. I have yet to see one that is not flawed in how it implements its tests tho.
> has more available commercial software,
Almost all of which also runs on FreeBSD tho,and usually with less trouble, and at times with better performance, so no reason to use one over the other.
> has wider backing,
Definitely. Windows has even wider backing..
> and most of all IS SUPPORTED LONGER
And needs to be supported longer also.
But let's see. Versioning in FreeBSD works somewhat different then in Linux since there is a much closer relation between kernel and userland. Transition between versions is rather painless (unlike upgrading a redhat installation for example) and one of my servers here has not seen an install cd for half a decade now, nor has it been d
> I wonder if it is a data transmission limitation? My understanding is that this is why cell phones don't receive a name from the caller ID, just a number. It saves connect time.
Makes a lot of sense to me for cellphones with their limited bandwidth.. A don't see why this would be an issue for landlines, see below.
> In the US the comptetive local carriers use their own switches for PTSN and more often ISDN/PRI and T1 lines, so they all have different standards for what they display that are usually more complete. The larger bells used to have varying equipment in rural areas but that seems to be more consistent here now. I'm not sure if it's the same in Germany
Callerid on pstn is a hack, not entirely unlike touchtone, and similar to text messaging over pstn connections. As a result, many providers ended up with similar yet different implementations.
What I am starting to think is that in the USA callerid was there already before any 'modern' phones became affordable, while overhere it was the other way around.
When talking about isdn, it would be good to look at bri instead of pri, a business may get a pri, but the average consumer doesn't. If they have isdn, it will be bri.
bri in Europe is similar but not identical to bri in the USA. A bri in Europe normally consists of 2 64kbit/s, 8bit B channels, and one 19.2kbit/sec 8 bit D channel. Your carrier provides the circuit including a nt1. In the USA, B channels can be 64kbit/sec, 8 bits, but you will usually find either 56k or 7 bit, the D channel however is the same. Usually you have to buy a nt1 yourself. All signalling happens on the D channel, including the sending and reporting of callerid (and short text messages, and heh.. you can actually use it as an alternative (slow) data channel as well, sometimes without any connection fees)
At any rate, overhere you send the individual caller id yourself (this is so you can select any of the upto 8 numbers that can be connected to such an isdn line) and this is normally checked by the switch your phone is connected to (when isdn was relatively new here, there were many problems due to too strict filtering, ie, must include country code, or must exclude leading zero for area code, and this was different for each telco, and often even different depending on where you connected to a telcos network)
When looking at a primary rate interface here, we get more D channels, so even more signalling capacity, but also more B channels. Effectively you get 2048kbit/sec. (this is similar to what we'd call an E1, more or less equivalent to what you call a T1, tho a bit faster)
At any rate... the signalling over isdn is mostly standarized, and when reading a trace, the only real differences I see between a European originated connection and a USA originated connection are the available 'services' (ie: 64kit data, 56kbit data, voice etc). The actual procedure for setting up a connection looks identical.
At any rate, different European countries have slightly different implementations (ie, in the Netherlands we usually get upto 8 individual numbers connected to a bri so you can address multiple devices individually, in Germany you use an identifier (msn) to signal a specific device on the s0 bus instead)
The underlying standard however is the same, and while equipment varries in brand and type, it is rather standarized and I haven't seen it cause 'weird' transmission limitations. In fact, on any bri, most of the D channel's bandwidth goes unused, and sending the little bit of extra information would not be any issue whatsoever.
Making 64kbit data connections from one side of the continent to the other side, using different telcos is normal, you don't get a 56kbit circuit inbetween all of the sudden or other such 'nonsense' either.
Of course this is all a bit different for pstn, but by now, we happen to have text messaging over pstn here (the Netherlands) as well, so I doubt it would be transmission related that only the number is s
Slashdot Mirror
In the last 6 months I had 2 harddisks crash.. it happens.
> Is dictation really the most common or most useful application of speech to text?
Definitely not..
> If you are using it for dictation then a long training period is acceptable.
Well, depends on 'long'. For most practical uses, peopel seem to find 3+ hours of training for it to be too much, unless they have a very direct purpose for entering text without needign their hands.
> But I find voice recognition in use much more often in phone IVR systems. When I call up my power company it asks me to say my account number. When I call a major hotel chain it asks which property I want info about and connects me appropriately. I saw a demo from IBM several years ago where they were doing money management and the system was recognizing mutual fund names. Movie theatre listings, 411, and the list could go on.
The complexity of speech recognition depends ALOT (to put it very mildly) on how big the vocabulary is that you are usign, and how many similar sounding words it contains.
All the things you list would be relatively simple, and won't require much if any training because they can rely on distinctive words froma small vocabulary.
This could be done with general purpose computing hardware like a decade ago, and was first demonstrated by IBM in the late 60s.
It is seriously different from what is required for generic speech to text for situations where you have no clue whatsoever what a user might be going to say.
To give you some exampels of the problems generic speech to text translation runs into:
Did you just say to? too? two?
It is only possible to tell if you have the context for it. In generic speech to text, that is a lot more difficult then when you are listening for very specific words and have determined the context beforehand.
> Not only are these things that are probably a lot more commonly used than dictation, but they are also the things that would save companies the most money. For the price of something like Dragon Dictate most people would save money hiring some starving college kid to type up whatever it is for the frequency they need it. Being able to shut down call center locations instead of just outsourcing them to India or the prison system saves a lot more money.
No doubt but the question is how usefull this technology will prove for that.
As mentioned before, there is a huge difference between listening for a list of words and doign generic speech to text.
> Will a general purpose CPU fit or operate in a phone that can be on for a week? I almost never shut off the phone and it still lasts a week, and I don't want to sacrifice that run time for speech recognition.
Good point, but with modern cpus and no need to have the speech recognition software runnign all the time, I think you can indeed have a phone with a long lastign battery, and still have a fairly powerfull cpu in there for the few moments where you really need it. For doign relatively accurate speech to text translation you need somethign faster then a p90, and I think there are mobile phones out there that manage that already.
Most of the time, a phone is left in 'standby' mode, which doesn't require much, given that you can tell the cpu to go sleep/slow down.
Don't get me wrong btw, I do see a use for the speech recognition hardware, but I'd think that use is for rather specialized devices.
> task specific silicon becomes very useful when you don't have as much space/power/heat-disipation as you want.
Definitely, and I see quite soem uses for that...
People use portable recorders for dictation now.. it would be cool to have such a small handheld device that does speech to text translation instead.
10 years ago, a 486dx33 together with a specialized dsp could do it, so I bet with this new piece of silicon and some low class cpu it is also possible.
Hmm. so that is where the possible niche for this hardware is I guess.
A small sidenote regarding 3D graphics accelerators and general purpose CPUs, whle you are absolutely right regarding the huge increase of cpu power offsetting the special hardware of such cards over time, we also get a new generation of 3d graphics hardware every so often, and there is a lot of room for improvement there still. Somehow development of the old PDS hardware was stopped as soon as CPUs became capable of doing the job.
> 100 to 1000 times more efficient worth $1M? meh. maybe.
> 100 to 1000 times more accurate worth $1M? definitely.
Accuracy does not have to be a problem with modern speech to text systems, but the need to 'train' them to get that accuracy, and the need to talk to it in a somewhat distinctive way, make them far less efficient.
I'd rather say that the time it takes to get used to a speech recognition system (and to get it used to you where appliable), together with the soemwhat heavy cpu requirements, are what currently stops use. To me that means that the first thign that is required is efficiency, the accuracy is already there.
(I have been using speech to text for over a decade now, starting out with another hardware solution in the first half of the 90s (IBM's VoiceType Dictation, back then called Personal Dictation System if I'm not mistaken, and even that system already had an almost as good accuracy as I manage myself)
During 1994 upto 1998 I did marketign and technical support for IBM's Voicetype Dictation products..
Initially, doing anythign beyond understanding a few words would take special hardware, but after a bit of 'training' highly acurate and fast speech to text was quite a possibility with a specially developed dsp.
Then, the pentium class cpus came about, and a p90 could just do the whole thing without the dsp.
So, now someone is developing a new dedicated piece of silicon for this.. lets see how long it takes for general purpose computers to catch up.
The issue is not that this is not usefull, but that it either has to keep developing, or offer a somewhat longer lasting price/performance ratio or much better features for a logn time to come.
Years ago I used Notes mail, cc-mail and profs on some IBM mainframe.. all were company wide 'private' mail systems that would allow selective communications with other parties (that used the same systems).
How is this dmail different in what it offers?
Very informative. I'd like to point out however that a situation somewhat similar to GDI may exist on Unix platforms (including Linux) as well when you happen to require dri.
> Yeah you're just making this up because you don't have an answer. What was this "slight difference", and why did you have to figure it out, eh? Come on, you challenge me to provide facts, you haven't provided a single one.
RH 2.4.22 kernel properly supported acpi while gentoo with a 2.4.22 kernel did not. RedHat imported patches from the 2.4.23 pre series.
> The Linux kernel has never been released for "marketing" reasons. Linus has never even worked for a company that markets Linux.
Linus releases things when he believes them ready, agreed there. That said, in both Linux and FreeBSD things come as they come, and the argument of 'too late' doesn't seem to make sense in either case. Maybe you should learn a bit about sarcasm here.
> That is 2 years old, and way before Linux 2.6 was released. It was close to the start of the Linux 2.5 development cycle.
The issues being discussed are still relevant, most importantly, signal delivery to threads.
> No that doesn't break all old apps that use libpthread. Why do you just claim that sort of FUD? FreeBSD 5 actually cannot pass the NPTL compliance test suite.
Hmm, you are right indeed that it doesn't break all of them, only those that rely on the old way of signal delivery.
> cdrecord dev=/dev/hda
Thanks, hadn't tried that for some time now, and on my 'modern' workstation it indeed works with the 'atapi' support only (it had failed on my server without the ide-scsi 'hack'). See, providing actual arguments can be informative and makes discussing worthwhile.
> Linux has one interface. It is accessable through ifconfig, ip, etc. It has a number of layers (sockets, tcp, ip, ethernet, tunnels, etc). If FreeBSD didn't have the same layers it would be useless. Tell me what you you mean by Linux having a zillion layers.
Sorry, that was bad wordign on my side. Should have said, has a zillion similar implementations of the interface.
> apt-get install pppoe
So I do have to install an external package for it. That is not goign to be very helpfull really when for example doing a network install over a dsl connection.
Let me just correct you on a few small points...
> how you connect this to the fact that the french are the laziest pieces of shit in Europe, I have no idea. Ingrateful, lothesome, delusional, meritless waste would be a good word for the french. THey want to drag the rest of Europe down to their level. Otherwise they would be forced to match the level of industry exemplified by the Germans, the Italians, the English, and the Spaniards.
Last time I checked, most industry in Brittain is gone (they trade, but don't produce that much), Germany has economic trouble beyond belief, Spain is not doing that well really either and nor is Italy. Only the UK is doign relatively well from all the examples you gave, and they are not similar in how their economy works.
> God forbid that happen to the race that considers multilingual signs to be an insult to their culture.
While I agree with the udnerlying sentiment (French being absurd with regards to protectign their own culture) your statement is factually untrue, and could apply as easily to the USA.
Fact is that the French require products sold in their country to INCLUDE texct in French (besides any other languages).
You may find virtually identical rules in other EU countries, this has to do with that the consumer is supposed to be able to read whatever is in a product.
A somewhat silly situation is the French requirement that any websites run by French companies must be in French (and can optionally support other languages) regardless of if they aim at a French public or not.
At any rate... quite a few Europeans tend to call France 'little America' and with good reason, you'd be surprised how well the USA and France compare when ti comes to blind nationalism, unfounded national pride and fear of anything 'foreign'.
> That isn't lack of direction, there were problems with the page scanning code and so it was replaced with a better version. Yes it was unfortunately a stable kernel series and that wasn't good at all, but the alternative was to either fix it or always have an unstable "stable" series. That doesn't say anything about lack of direction.
> As I said, this wasn't lack of direction. I suggest you look at the fiasco that is FreeBSD 5. Their operating system is *years* late, and the lack of direction splintered its developers (yes, including resignations and a fork).
> Why would that be "too many"? You've skipped the "lack of direction" question, and made this assertion. What is the problem with having different vendors offer different sets of kernel patches.
> What was the last thing you had to do differently because two vendors offered different kernel patches? How much did it cost you?
The last time was when I had to figure out why the fuck some RH 2.4.x based kernel worked slightly differently then a Gentoo one (my normal testing environment) for a for my customer relevant situation. It costed approx 2 hours to figure out where the exact difference was between 2 kernels with identical version numbers, both compiled with identical options, but not from the exact same source (redhat patches)
Supposed purpose of a 'stable' version, provide a stable version.
Reality in the Linux kernel was implementing something that was not proven and could not be considered stable yet (the vm).
I consider that lack of direction.
I don't blame the developers for not getting it right the first time around, but I do consider having this happen in what is supposedly a stable version to be a major issue.
What happened with FreeBSD 5 happened in the development release, not in something that was supposedly stable and ready for normal use.
It gets released when it is ready as opposed to when it is convenient for marketing reasons.
There will always be issues that result in controversy and disagreement. FreeBSD keeps that out of the stable releases that peopel count on, and breaking the binary interface in stable releases is not done.
Linux has not been able to keep that out of stable releases, and has had multiple cases of breaking binary interfaces in supposedly stable versions.
As for pthread support, FreeBSD 4.x lacks kerel schedulable units and can be said to not be fully pthread compliant.
With regards to Linux and FBSD and pthread support, a nice bit of dicussion can be found at http://kerneltrap.org/node/view/422 for example.
FreeBSD 5.x is as possix threading complient as it gets while Linux suffers from some small issues regarding signalling (officially fixed when usign 2.6 and the new phtread library, but that breaks all old apps that use libpthread)
> Linux kernel is fully device hotplug capable for hardware that supports it
> Linux doesn't need "a zillion" layers. Linux uses SCSI for everything other than PATA controllers, which it uses a seperate IDE layer for. 2. FreeBSD also has an IDE layer.
Ah, tell me then how to get an ide cd/dvd burner to work without the 'ide-scsi' hack.
And yes, FreeBSD has an ide layer as well, but for any relevant devices this neatly plugs into the underside of CAM.
> No it doesn't
You obviously never saw how netgraph works, so I'll excuse you for not realizing the difference and not seeing how linux does in fact provide a zilion similar layers instead of one.
Tell me, how do you get pppoe to work without the rp-pppoe package? just saying it does, does not prove anything at all, and anything I can find on google as well as my own experience tell me I need that 3rd party package to get it to work.
Just in case you want to know, on a stock FreeBSD machine, you load the pppoe kernel module and it works. No compilation needed, no external packages needed, nothing of that all.
Again, calling yes/no makes for unfounded claims. Back them up or shutup. If you do not have anything to contribute in the BSD section other then proclaiming Linux superiority, without backing up your claims, then you are the troll here my friend.
> No, you implied that that actually was the case. You said words to the effect of "too many people mess things up, that applies to linux".
I refered to a well known saying. If you have too many people working on something, that does not result in better results, more likely in worse results.
That was an answer to the implication in the parent post that more people means better results by definition.
And yes, that implies that this could well be the case for Linux.
> You are a fine person to accuse me of baseless and factually wrong claims. What lack of direction in Linux?
It is a little while ago now, but I'd suggest reading up on the VM related discussions with regards to Linux for a nice example.
I'd also suggest looking at how many Linux distributions come with their own collection of kernel patches.
The later is a direct result of too many different people/organisations with different priorities.
It is also a direct cause of it beign more expensive to support for me. The only way around that is to support one single distribution only.
> As opposed to what in FreeBSD?
A single distribution, features that are claimed to be there actually work (ACLs, large file support, complete pthread support to just name some examples)
> How can it be directly linked to the people working on it?
Again, check out for example the VM situation in 2.4
> Again, back up these claims: what lack of structure, how does it link directly to the people, how is FreeBSD different?
I clearly stated that those were my personal experience. It is what applies to my situation, yours may be different.
The lack of structure was a claim independent of my experience, but for example FreeBSD gives you a clear and easy to handle source tree, including ALL tools you need to build it and all tools that depend on it. In case of Linux, I need to go collect the kernel source, binutils, filesystem utils, correct compiler etc from different places (not even talking about 'normal' userland tools here)
In case of FreeBSD those have been tested together, and produce a predictable result. You also simply do not have to put efford into ensuring you get everything in the correct versions yourself.
For as far as the kernel itself goes, I'd for example take a peek at how support for removable media and ide cd devices etc works. The same applies for non-ethernet network devices for example.
FreeBSD uses CAM for supporting anythign that can work as if it is a scsi device, instead of needing a zilion different layers depending on what physical connection the device happens to have (scsi over ide to just point you at one specific example)
FreeBSD uses netgraph for supporting any type of networking interface, providing for a structured way of defining and supporting network interfaces without having to deal with their physical properties, whereas Linux has a slightly different layer for each type of network interface (and doesn't support somewhat relevant things like PPPoE without a 3rd party tool)
It of course may have to do with lack of design capabilities but I honestly do not believe that is the case with the core Linux developers. The only alternative explanation I can see is too many people workign on similar things independently and not integrating their work properly.
Glad to see that at least you are willing to discuss and left the name calling and assumptions out. I am quite willing to discuss as well in that case.
> No you didn't. You said (maybe indirectly) that the Linux kernel was being mucked up by having too many people working on it.
I implied that that might well be possible yes.
> What I find very hilarious is that BSD zealots who are now trying to claim that Linux must be worse because it has *more* people working on it.
Lack of direction, lack of knowing what you can count on with Linux? yes, those are issues when using and supporting it, and can directly be linked to the huge diversity of people working on it and their conflicting priorities.
More people working on it also means more resources.
What works out better is not that easy to say, and depends a lot on what you need.
I do know that for me it is approx 30% cheaper to support a FreeBSD server instead of a functionally equivalent Linux setup simply because of the lack of structure in Linux (which results directly from the diversity of people working on it)
I also know that it is easier (and as a result cheaper) for me to support a linux desktop on some random piece of hardware exactly because of the same diversity.
For the rest, if your claim about 'BSD zealots' were true, that would just make it a typical case of pot and kettle.
- Look at which slashdot section this is posted in
- Look at the original post I replied to.
What does it have to do there other then trying to do the exact same thing you are accusing 'BSD zealots' of?
At any rate, reply to this if you feel so inclined to having the last word, but unless you actually provide some kind of argument and back it up (as opposed to making assumptions which are based on very little and are factually wrong), I'll ignore your replies.
> Let me see... I suppose you think FreeBSD is cool and most scalable and has the best networking stack and is the fastest and most sable and second most secure (behind OpenBSD, of course) and best engineered and consistient and cool and best networking stack, and most stablest operating system evar, right?
Nope, neither do I think Linux qualifies for all those. Both systems have their merrits and disadvantages.
What I was pointing at here is that the fact that a zillion peopel are involved can be as much a disadvantage as an advantage, and as a result is a stupid argument to make.
> Nice. Linux must suck, eh?
I do commercial support on both Linux and FreeBSD, I run both for commercial and private purposes also and I maintain a small Linux distribution together with a friend (as well as maintaining my own variation on the FreeBSD distribution)
I have been using both systems since the first half of the 90s (pre 1.0 versions of linux and 2.0 beta of FreeBSD were the first versions I worked with)
I have made contributions (abeit small ones) to both systems.
I do think I have some background here. Now, what do you have to base yourself on? claims from an AC who doesn't even provide anything like an argument or background for making those claims are pretty silly.
It seems to me that when you replace FreeBSD with Linux in your post, you exactly get the opinion of zealots like you.
What I find rather hilarious is how stupid some (luckily by far not all) Linux fans respond to anything that might be remotely critical of Linux.
It depends a bit on what you want exactly.
/usr/ports/sysutils/livecd for creating a nice customized 'live' cd.
/usr/ports/sysutils/livecd; make /usr/src; make release
You may want to look in
You may want to check the handbook on generating releases if you want to build your own customized 'release' that can be installed from cd (or floppy or over a network etc)
Very roughly it comes down to either
cd
or
cd
> Also FBSD 5.3 is in debug mood which makes it slow while 4.10 is normal.
:) anyway.. with the default install it is indeed. Instructions for changing this when compiling your own kernel (try it, its really simple) can be found in /usr/src/UPDATING
/usr/ports/misc/instant-workstation; make install /usr/ports/misc/instant-server; make install if you are installing a server)
mood?
The debug settings in the stock 5.x kernel slow it down, but it supporting much faster ide controllers properly and making better use of resources on hyperthreadign and smp machiens can easily offset that, so you may still find the 5.3 beta to be faster then 4.10
> 4.10 has the latest utilities and apps that fbsd 5.2 lacks.
If you use the ports collection, that is definitely not true, both run approx the same set of applications in whatever version you install (the latest usually when you keep your ports collection uptodate). Also, 5.x comes with newer versions of gcc and related tools for example.
I'd say.. if you intend to try this on relatively new hardware, wait till 5.3 gets released. Otherwise, go with 4.10
In either case, ensure you install the ports collection and the cvsup package (you will eb asked about the first while selection the distributions to install, and you can get the later by answering 'yes' to the question if you want to visit the configuration panel at the end of the installation. Select packages there, and add the cvsup package)
When at the configuration panel, you should also configure X and a desktop if you intend to use this as a workstation.
Then, after install and reboot, do a cd
(or cd
> Let's see. ......
> all employ full time staff to work just on the
> Linux kernel. Apart from hundreds of other small
> companies, governments, educational institutes,
> thousands of volunteers.
Ever heard what too many cooks do to a potentially good dish?
Seems rather appropriate in case of Linux...
Next time you happen to encounter a unix like system (other then Linux that is) *I suggest you try the man command.
man cp would have told you exactly what you needed to know.
Which is too bad. the similar clause in the BSD license was removed for good reasons, and without wanting to give any judgement as to the quality of Hsu's work, he obviously did not get the clue there.
I can read that many ways.. yeah, also as a troll, but 'funny' was really the first thing that came to mind, not troll.. and it is factual.
I'd really appreciate it if my fellow BSD users would get a bit more of a sense of humor etc...
Heh, for example for webservers this is kindof relevant...
> Yeah, it really pisses me off that The GIMP only works on two distros.
> FFS, get over it, man. There's no "incompatible Linux distributions". You name me THREE open source apps (exclusing the obvious installers and config tools) that only work on one distribution.
Ignoring the point is not really going to help.
Yes, I can run vrtually any opensource package on any linux distribuion and any bsd distribution.
Since each and every linux distribution comes with a slightly (or at times wildly) different set of libraries and versions of libraries, there is no guarantee that you can take a binary from distrivution x, and expect it to run without any hastle on distribution y. Yeah, you can definitely get it to work by installing extra libraries or recompiling the thing.
> Struggling? Thought so. Your talk about "incompatible distributions" is ignorant and ill-informed. 99.99999% of open source apps work on all distros without any hassle.
Did you ever build comemrcial Linux software? I did. I also did the installer. There is a good reason for most commercial software either supporting only a few distributions (officially at least) or being statically linked to most stuff they happen to depend on.
You obviously never looked at what those nice installer scripts do but you may find funny things as binary distributed software installing differently based on for example your version of gcc, glibc and a few other such things.
> ATEOTD, Linux has broader hardware support,
Possibly, especially when it comes to non x86 hardware.
I use fairly modern x86 hardware for a whole variety of purposes (including hosting and network infrastructure), and I have yet to encounter a device that I actually want to use that is not supported.
The same can be said about Linux, so no difference there as long as you keep to a supported platform of course..
> runs faster, has better SMP,
If Linux runs faster is rather debatable. My test server runs both FreeBSD current and gentoo with linux 2.6 kernel in a multiboot config. (it is a dual cpu machine btw)
Running exactly the same Apache configuration, in both cases compiled from source, results in the fbsd version handling between 5 and almost 20% more requests/time on a mix of static and dynamic (php and perl) content.
I have the same systems installed on my workstation, an adm athlon xp 2600+ with 512mb and a gforce4 mx.. When running FreeBSD 5, my favorite multiplayer fps (Enemy Territory) runs substantially better then when running Linux (somewhat interesting seeing how this is in fact a Linux binary)
Both annecdotal evidence at best, but definitely 2 cases where Linux doesn't run faster.
With regards to SMP, esp. on non x86 hardware Linux does a lot better, but then, FreeBSD doesn't run on most such hardware to begin with.
If this is true for x86 hardware is debatable, and I'd like to see what things look like once 5.x has been 'stable' for a while, and I keep an eye on dragonfly and their smp work.
I have seen some performance comparisons that were at least trying to measure things instead of basing themselves on annecdotal evidence.. I have yet to see one that is not flawed in how it implements its tests tho.
> has more available commercial software,
Almost all of which also runs on FreeBSD tho,and usually with less trouble, and at times with better performance, so no reason to use one over the other.
> has wider backing,
Definitely. Windows has even wider backing..
> and most of all IS SUPPORTED LONGER
And needs to be supported longer also.
But let's see. Versioning in FreeBSD works somewhat different then in Linux since there is a much closer relation between kernel and userland. Transition between versions is rather painless (unlike upgrading a redhat installation for example) and one of my servers here has not seen an install cd for half a decade now, nor has it been d
Hehehe, seems its even more dangerous then I thought then.... ;)
> I wonder if it is a data transmission limitation? My understanding is that this is why cell phones don't receive a name from the caller ID, just a number. It saves connect time.
Makes a lot of sense to me for cellphones with their limited bandwidth.. A don't see why this would be an issue for landlines, see below.
> In the US the comptetive local carriers use their own switches for PTSN and more often ISDN/PRI and T1 lines, so they all have different standards for what they display that are usually more complete. The larger bells used to have varying equipment in rural areas but that seems to be more consistent here now. I'm not sure if it's the same in Germany
Callerid on pstn is a hack, not entirely unlike touchtone, and similar to text messaging over pstn connections. As a result, many providers ended up with similar yet different implementations.
What I am starting to think is that in the USA callerid was there already before any 'modern' phones became affordable, while overhere it was the other way around.
When talking about isdn, it would be good to look at bri instead of pri, a business may get a pri, but the average consumer doesn't. If they have isdn, it will be bri.
bri in Europe is similar but not identical to bri in the USA. A bri in Europe normally consists of 2 64kbit/s, 8bit B channels, and one 19.2kbit/sec 8 bit D channel. Your carrier provides the circuit including a nt1. In the USA, B channels can be 64kbit/sec, 8 bits, but you will usually find either 56k or 7 bit, the D channel however is the same. Usually you have to buy a nt1 yourself. All signalling happens on the D channel, including the sending and reporting of callerid (and short text messages, and heh.. you can actually use it as an alternative (slow) data channel as well, sometimes without any connection fees)
At any rate, overhere you send the individual caller id yourself (this is so you can select any of the upto 8 numbers that can be connected to such an isdn line) and this is normally checked by the switch your phone is connected to (when isdn was relatively new here, there were many problems due to too strict filtering, ie, must include country code, or must exclude leading zero for area code, and this was different for each telco, and often even different depending on where you connected to a telcos network)
When looking at a primary rate interface here, we get more D channels, so even more signalling capacity, but also more B channels. Effectively you get 2048kbit/sec. (this is similar to what we'd call an E1, more or less equivalent to what you call a T1, tho a bit faster)
At any rate... the signalling over isdn is mostly standarized, and when reading a trace, the only real differences I see between a European originated connection and a USA originated connection are the available 'services' (ie: 64kit data, 56kbit data, voice etc). The actual procedure for setting up a connection looks identical.
At any rate, different European countries have slightly different implementations (ie, in the Netherlands we usually get upto 8 individual numbers connected to a bri so you can address multiple devices individually, in Germany you use an identifier (msn) to signal a specific device on the s0 bus instead)
The underlying standard however is the same, and while equipment varries in brand and type, it is rather standarized and I haven't seen it cause 'weird' transmission limitations. In fact, on any bri, most of the D channel's bandwidth goes unused, and sending the little bit of extra information would not be any issue whatsoever.
Making 64kbit data connections from one side of the continent to the other side, using different telcos is normal, you don't get a 56kbit circuit inbetween all of the sudden or other such 'nonsense' either.
Of course this is all a bit different for pstn, but by now, we happen to have text messaging over pstn here (the Netherlands) as well, so I doubt it would be transmission related that only the number is s
> Is it obvious to anyone else that /. has happily traded in sanity for advertising dollars?
Slashdot had sanity?