True zerocopy has certain hardware and driver requirements. These are the network drivers in linux 2.5.9 which support zerocopy TCP: 3c59x, acenic, sunhme, 8139cp, e100, ns8320, starfire, via-rhine, sungem, e1000, 8139too, tg. (Disclaimer: Not all cards supported by those drivers necessarily support full zero copy). That's from grepping for the NETIF_F_SG and at least one of the NETIF_F_(IP|NO|HW)_CSUM flags.
In Linux, zerocopy is performed using the sendfile(2) system call, rather than writing to a socket from a memory-mapped file, as you are meant to do with the new BSD code. Although the mmap method is a neat way to make a few existing programs faster, it is less efficient than the sendfile() method, to some degree, and certainly more complicated to implement.
A write-from-mmap implementation has to provide a certain allowances for user space behaviour. Although it's advised not to touch the pages from user space, allowance for this basically require the OS to "pin" pages, either by modifying page tables which implies TLB and page walking cost (if the pages are actually mapped, which they probably are not in a Samba/www/ftp server), or by at least pinning the underlying page cache pages in case someone does a write() to the mapped file. sendfile() does not require the pages to be pinned, because it provides different guarantees about which data is transmitted if the data is being modified concurrently.
Another nice thing about sendfile() is that it's quite fast even for small files. The overhead of calling mmap() and then munmap() may outweigh the copying time for a small transmission. Basically, why bother with mmap/write/munmap when you can just do a sendfile, which doesn't require the kernel to jump through hoops to decode what you meant.
Well, I don't know if it makes much difference in performance if you only mmap() a file without referencing the pages from user space, and write it to a socket. We'll have to wait for the numbers.
But there is another great thing about sendfile! You can use it to transmit user-space generated data, such as HTTP headers, too. This is done by memory-mapping a shared file (such as a pure virtual memory "tmpfs" file, but you can use a real disk file too). Then you can write to that mapped memory from user space, and call sendfile() to transmit what you have just generated.
You can do what I just described, with a mapped, shared file, using the new BSD zerocopy patches too. If using sendfile(), the weaker concurrency guarantees of sendfile() vs. write() mean it is your responsibility to not modify the data until you are sure it's been received at the far end. In some ways user space has more responsibility, to be carefully manage the data pool with this method of using sendfile() for program-generated data, than using BSD-style write(). On the other hand, that's exactly why the BSD kernel must do more work of pinning pages, and in this mode of usage there is definitely TLB flushing cost and cross-CPU synchronisation cost, so if you are really crazy for performance, sendfile() may just have the edge. (Well I expect so anyway, I haven't done performance comparisons).
By the way, write() from memory-mapped files has been discussed among linux kernel developers several times in the past, and each time the idea lost due to the feeling that page table manipulation is not that cheap (especially not on SMP), and now that we have sendfile... Well, if you were writing a really high performance user space server, you'd use sendfile anyway so writing from mmap becomes a bit moot.
Finally, zerocopy UDP is not implemented in linux at present as far as I know, but some gory details were discussed recently on the kernel list so it is sure to arrive quite soon. The difficult infrastructure (drivers, page-referencing skbuffs) which is used by the zerocopy TCP implementation has been part of the 2.4 kernel since 2.4.4 (more than 1 year ago) and I believe it has been thoroughly tested since then.
Enjoy,
-- Jamie Lokier
You company does not have permission
on
Abusing the GPL?
·
· Score: 4, Informative
(BTW, I am not a legal advisor. This is my understanding of the GPL).
If you are including other people's GPL'd source code in a program which you distribute, then you must abide by the terms of that license. Section 3 of the GPL is precise enough to disallow scrambling the source code:
You must provide the source code of the whole GPL program to your customers, as defined in clauses 3a, 3b and 3c.
The provided source must correspond exactly with the binary that you give your customers. So it must include your modifications, for exactly that version.
The provided source must be in the "preferred form of the work for making modifications to it". That means the source code must be what you actually load into your editor to develop the software. In other words, you must distribute the useful source code.
There is nothing to stop you changing all the variable names, or the style of someone else's code. However, if you distribute a GPL'd binary then the source you distribute with it must be the source that you prefer to use for modifying the program yourself. You may be called upon to prove this in a dispute.
For reference, section 3:
3. You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:
a) Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,
b) Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,
c) Accompany it with the information you received as to the offer
to distribute corresponding source code. (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such
an offer, in accord with Subsection b above.)
The source code for a work means the preferred form of the work for
making modifications to it. For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable. However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.
If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.
Absolutely no way I'm installing any software on my computers that comes with the conditions below:
2.2. Server Use. With respect to the Blender Stand Alone Player and Blender 3D Plug-in only, and subject to the terms of this Agreement, you may install one copy of such Software on a computer file server within your internal network for the sole and exclusive purpose of using such Software (from an unlimited number of client computers on your internal network) via (a) the Network File System (NFS) or (b) Windows Terminal Services. Unless otherwise expressly permitted hereunder, no other server or network use of the Software is permitted, including but not limited to using the Software (i) either directly or through commands, data or instructions from or to another computer or (ii) for internal network, internet or web hosting services.
2.3 No Modification. You may not alter or modify the Software or create a new installer for the Software. The Software is licensed and distributed by NaN for viewing, distributing and sharing.blend files. You are not authorized to integrate or use the Software with any other software.
3. Intellectual Property Rights. The Software and any copies that you are authorized by NaN to make are the intellectual property of and are owned by NaN and its suppliers. The structure, organization and code of the Software are the valuable trade secrets and confidential information of NaN and its suppliers. The Software is protected by copyright, including without limitation by Dutch Law, international treaty provisions and applicable laws in the country in which it is being used. You may not copy the Software, except as set forth in Section 2 ("Software License"). Any copies that you are permitted to make pursuant to this Agreement must contain the same copyright and other proprietary notices that appear on or in the Software. Unless specifically and expressly permitted by NaN, you agree not to modify, adapt or translate the Software. You also agree not to reverse engineer, decompile, disassemble or otherwise attempt to discover the source code of the Software. Except as expressly stated herein, this Agreement does not grant you any intellectual property rights in the Software and all rights not expressly granted herein are reserved by NaN.
The point of the GPL is to prevent *hoarding* of code, in order to guarantee everyone who has a use for the code certain freedoms to use it.
IMHO it's a shame that this inevitably leads to license conflicts with other kinds of free software. But there is no way to prevent hoarding without also preventing some other uses. Ah well.
Although you have a valid point, you need to realize that this offer comes together with a bold move by the government to put everything on the internet; there are a lot of projects going on to make sure that in a few years time, it is possible to do everything online, from filling in taxes to paying a parking ticket. So a lot of people do not have a good use for a cheapo PC at this time, but that will change when all that stuff gets online (you need to interact with the government quite frequently in here) -- and when they only go get one at that time they may find themselves seriously lagging behind in skills compared to those who get a PC now.
And if all those computers are running Windows XP, the government service web sites are free to require use of a Microsoft browser. Which means that if you'd choose to uninstall the Windows XP and switch to something else, so that you can learn more about how computers work, you won't have that option. So much for empowering the poor, eh?
It's a nice way to guarantee that Digital Rights Management stuff (i.e. to prevent you from "unauthorised playing" of movies), without actually making it law, too.
One day, I incorporate 1/4 of a Free software package's code into my new program, so I need to cut and paste, say, 1/4 of the documentation for the package to make the documentation for my program.
At which point, having to send changes to parts of the documentation for my program back to the authors of documentation for a different program is a waste of everybody's time.
It depends on the kind of compression. With V.42bis, you are probably right.
There's a school of thought that says: Compressing closer to the modem stack gives you marginally better real time response, provided the compression itself is just as good. This is because you can postpone decisions about where to place packet boundaries, and how exactly to compress the last symbols, until just before a packet must be emitted. In fact, with the V.42 protocol, you can defer selecting the packet boundaries until you're in the middle of a packet.
This would be a win with, for example, a Bzip2 style of compression (block transform), if you had the choice between doing the transform in the IP layer or doing it at the last possible moment in the link layer.
I agree that for V.42bis/MNP5/V.44, given the possibility of PPP compression, it's probably better to use just PPP compression. I'd like to see measurements though.
So you like specialized hardware? This project helps towards the goal of specialized Free (as in speech) Hardware. Just because it works on an Athlon doesn't mean it can't be ported to a GnuDSP, or even a GnuFPGA with good tools.
The patents are a real problem. I'm not sure what to do about them for, say, the commercial distributions, but I don't see them having a serious leg to stand on w.r.t. freely distributed code for personal experimentation/education purposes. It's the user's problem to verify that they have the appropriate licenses, particularly as 99.9% of users are likely to have those licenses. It's perhaps the developers' problem to inform the users. As far as I know. (I would like a proper legal opinion though).
Interesting; I did not see this second message from Alex. Have I been unsubscribed from the list over the weekend, I wonder?
I'm going to answer a few questions that have been raised, and a few that haven't.
Is anybody working on the code?
Fabrice started first. Unfortunately, he has been quiet for a very long time, and I have no idea if Fabrice has done further work on the modem code. I hope he is still well and healthy.
Meanwhile, I have been secretly still working on my code base (that's the one at tantalophile) all this time. It has been an on and off affair, and I've found it difficult to find the time, energy or focus what with the day job and other projects. I keep foolishly trying to improve on the standard algorithms;-) Nevertheless, bugs have been fixed, features added, tests done, signals are processed better than ever and I have a nice set of graphs showing simulated error performance of the V.34 core under various conditions.
In other words, there's a long way to go and please, nobody hold their breath, but there has been substantial progress and it is not on the tantalophile web site. So don't slashdot it, thanks:-) I'm making no promises about when my new material will appear, but I do promise it will be announced on the linmodems mailing list.
About the bounty
It's a bit of a nice surprise to see that offered. I'll be contacting Alex, but to be honest I am motivated to complete the project anyway. I don't want funding to dictate the goals of the project (which should be educational and of high quality, IMHO, as well as functional), although some influence would be understandable. It is likely to make a difference to the schedule though.
Legal clarification and/or commercially backed negotiation on the patent issue would be invaluable, and help with testing is also very valuable.
I didn't respond to the original $5000 request because it is not a lot of money. Considering the large amount of time, effort and to some extent resources already spent on the project, as an estimate for the remaining work, I would certainly not accept a commercial contract at that sort of rate. $20000 is rather more interesting, but I think Alex's request for V.90 is unrealistic if he wants it on a short timescale.
One thing that would be a bit upsetting is if all my work were quickly overshadowed by someone else, suddenly motivated by cash, throwing something together. But I cannot complain as I haven't exactly been speeding ahead or keeping with the community on this. I know how the Hurd feels;-)
Standards compliance, approval, and "homologation"
This is quite hard, because anyone can modify the code and thereby break any certification of the code.
Different countries have different standards. There are differences in the energy that can be emitted, both the peak instantaneous energy and a longer term average are limited. And you don't always want to max out the energy anyway, as you're avoiding distortion.
The relationship between voltage and current is not the same everywhere. Dialing tones, engaged tones and so on vary. V.90 coding varies because the USA operates at a lower digital bit rate than most of Europe.
Some people have said that it is the hardware which is subject to regulation. This is not true. I believe there is a certain certification level for the hardware itself, for avoiding excessive energy input, making sure the hardware doesn't go up in flames when receiving the 100V ring pulses or a lightning bolt, that the impedance is matched, and so on.
However, it is (theoretically) necessary to certify the software as well for many reasons. A good example: by modifying the software, you can transmit more energy on a USA telephone line, using a USA modem, than is permitted by federal regulations. That excessive energy is considered to potentially interfere with other people's telephone calls. So, you do have to get the software right.
Fortunately we have a good example of certification in the Linux kernel. Some versions of the Linux ISDN code are certified for use on the German telephone networks, I believe. The source code is checksummed. I note with interest that it's the source that's certified, and not the binary (so the beurocracy is ignoring bugs in the compiler or the rest of the kernel).
For myself, I am very keen to write code which certainly does conform to all the known requirements. I don't feel comfortable hacking together some "it seems to work" code of this kind and releasing it like that. It's partly a reputation thing, and partly a responsibility thing.
On patents
Yes, there are many patents. Unfortunately the detailed patent situation is unknown. It is possible that the patents don't apply to software implementations in most countries, but we don't know to what extent and where each patent applies.
We don't even know which patents apply! However, there is an online list at the ITU which may be helpful.
This is hopefully an area in which Alex Pilosov and his (possibly) commercial backing can help in a big way.
I am of the opinion that users have, in general, already paid for their modems and so they should already have permission to use the techniques. It seems to be the case that software modem drivers for Windows are downloaded and installed with no attention paid to these matters, so it should not be any more of an issue for Free Software. It would be good to know for sure.
The developing world
Telephone line driver chips are cheap! For the developing world, getting an internet connection over crappy copper would be a wonderful achievement, and with full access to a software modem, you could cobble the modems together from parts.
For this reason I think it is important that the softmodem works well over poor lines as well as good ones. And yes, I would love to code "workarounds" for when the standard algorithms don't perform well on Nepalese copper lines, or wherever. It would have to be a special variant of the code, for the regulatory reasons stated earlier, but it's a lovely thought.
Is it still worth writing a software modem in order to use "winmodems" on Linux?
The motivation has certainly waned, now that many previously windows-only modems are now supported on Linux by binary-only drivers from the manufacturers. Of course, you cannot use them if you're using the wrong kernel, or SMP, or if you have more than one modem, if you don't permit binary-only drivers, if you are using an Alpha or a PPC-based iMac, or if you want to run any-BSD. But hey, a lot of users are happy enough now, so that does remove some of the motivation for writing the code.
Which leaves the educational aspect. The interior of a modern modem is not well documented, even in books about signal processing. To be sure, many of the classic algorithms are very well written up, but the details as they apply to modern modem standards are not, and there are some algorithms which V.34 and V.90 clearly require which I have yet to find any information about. (Welcome to re-inventing the wheel, but it is fun!) As Alan Cox once said, the V.90 standard is "semi secret". Read it sometime, if you don't mind paying the relatively modest fee, and you'll see what he means.
Revealing just how a modern modem works, in the form of working code that (I hope) is readable by those who wish to study it, then, is as much a goal for me as getting winmodems working. And it's interesting because I'm still figuring it out myself:-)
Interfacing with the hardware
Several people pointed out, quite correctly, that a software modem won't actually work with any of the hardware "winmodem" devices. This is correct; we need device drivers too, and that is accomplished by reverse engineering the original drivers.
I don't know Alex's exact requirements. He doesn't mention needing PCM drivers -- perhaps he has his own drivers already? But if he requires reverse-engineered PCM drivers as well then that's quite a bit more work.
Progress on that front is being made, by several people, but it is really a separate project. It is worth noting that there's a GPL'd Lucent modem driver that can do PCM. It is actually quite old now. I have faith that the PCM driver part of this problem will be solved by eager contributors if there is a good softmodem to make use of it.
Reread the article. Jon Katz is not laying the blame on anyone and neither should you. It is not politician's fault if they seem to be focused on the wrong part of the problem: they don't know any better. Politicians have kids, and some of them had unhappy childhoods too, you know? The solution here is to educate and direct the politicians. Give them good advice, good feedback. Help them to see and implement solutions. Make sure they feel good when they do implement solutions. Jon Katz is helping to inform policy makers, and so are you with your diverse opinions.
It's not parent's fault if they are "bad" parents. How many of you really know how to be good parents? Sure, a lot of us here seem to intuitively know the principles of good parenting. But just you try applying your principles when you really, really don't understand why you're kid 20 years younger than you doesn't seem to listen to anything you say to try to help. Most parents do sense when their kids are unhappy, and with some kinds they don't know how to help. They feel like they've tried everything they can think of. Don't blame the parents: that just makes them resent you more. More to the point: it confuses them. They can't see the answers when they, the parents that is, think you hate them. Remember, parents are kids inside too, and for all these troubled children who became happier adults, there are adults who are still as troubled as they were when they were children. If you think you have good parent instincts, apply them: do go and talk to children who near live you. Without offering candy.
You can't blame video games. And you can't blame lack of video games, which you do when you talk about how important it is that the games help you let off aggression. The simple truth is, and everyone knows it, that video games, and violent images especially in entertainment, do program a certain violence thoughts into your mentality. Don't take this as a bad or a good thing! It just is, and brings me to the next point:
Can you blame the perpetrators of crimes? I.e. is it their fault? Some say yes it is their fault and they do not get enough blame. Some say no, they are a product of their awful environment. I say both points of view are right. There is no contradiction. No paradox: in fact the paradox is a clue to look for another way of thinking. Move away from talking of blame.
People, including but not restricted to children, are programmed by their environments, and the things they watch on TV. Minds do have a strong mechanical, habitual nature. And everyone here knows it. Ever played tetris for weeks and then seen tetris figures everywhere you go? Your mind is mechanical; don't confuse it with you. Trust me, the tetris effect is the tip of a vast iceberg of habitual thought and emotion processes that most of us do not study in ourselves. We should, as the most frightening things are not "really" frightening when you know why you're reacting that way.
Back to environment. People are made resentful by the things that happen to them. Yet people including children are responsible for the TV they choose to watch. Often, they could do self-defence and other courses which would help them tackle bullies. They could talk to the other kids who are even more frightened and unhappy than they. You see, even children can be "blamed" for their own environmental programming, because they are presented with choices that they are afraid to take. Like taking a martial arts course, or talking to other strange kids, might be too scary, even if it's a patently good idea. Yet you cannot blame anyone for not doing something because they are too scared. Well, you can if you like but I assure you it does not help them to be less scared.
Do you blame the TV or the people? No, you should aim to teach the people to know how they are affected. There is nothing wrong with watching violent or playing violent games. But it does affect your habitual thoughts and emotions. So learn to be aware of the effects, and decide how to program yourself. This is the importance of know thyself. Well, one importance.
By the way, self-awareness lessens or enhances the effect of environmental programming on yourself, whatever you choose from situation to situation. This is the secret to being simultaneously free to do as you please while being in charge of the environment's programming of your own mind. This is why it's ok to play violent games, to love Marilyn Manson etc;). Those here who "play games and they don't make me violent" are proof of this.
Everything outside is some kind of bully, until you know how to deal with it. And then it isn't -- it's your friend, or at least an amusing sideline.
Laying of blame really is not the solution. It is helping, because as one thing and the next thing are "blamed", they are scrutinised. Every bit of the struggle helps. But it's maybe not the most efficient route to freedom and happiness.
As someone wiser than me said: we are interested in solutions, not problems. Blame is being interested in problems.
To a person who is in the verge of killing themselves, or committing some nasty act towards others, just knowing that life does get better is a wonderful gift. You've seen it among the replies here already. Lives are transformed by this simple knowledge. This is a far more beautiful solution than anything that comes from blame, blame, blame.
Just don't use that as an exuse to pretend that violent, and indeed other depressing images don't have a mental effect. They sure do. On everyone. The secret of happiness is remembering to put this where it doesn't hurt.
Oh god, I could go on and on:-) Remember even nutcases like me were unhappy children once:-)
thanks for reading, btw life really does get lots better as you get older,
-- Jamie
How is this any different from today, with copyright, where all programs and algorithims written down in academic publications (or publications of any kind) are available for all to use?
Today, programs and algorithms written down in academic publications are presently not available for all to use.
For example, go and look up the many papers on register colouring in a compiler. I believe you cannot use all some documented algorithms due to patents (which expire soon, fortunately).
Look up text in international standards like ITU-T V.8bis for modems, and you find a stern warning that implementing the standard may infringe on some patents (although you are not told which ones or how to find out).
The RSA encryption algorithm was documented in many papers, but until recently you weren't free to use it.
Take a look at the book "Numerical Recipes in C". It's a nice book describing numerical algorithms, but you are warned that the example programs are copyright the publisher, and you cannot just type them in and use them as-is. This leaves a questionable grey area, because you can presumably write your own code modelled on the code presented in the book.
In a world without copyright, all these things which are published in books and papers would be free for all to use.
Oops! The driver source is GPLed, it just doesn't refer to the "COPYING" file like I'd incorrectly remembered in the traditional GPL copyright template.
Ahem. The.dsp files, containing the modem algorithms, are still binary only though. The whole driver is still not free software. You don't have the freedom to port it to other hardware, run it over a sound card or a ham radio, modify the signalling methods, or study the DSP code to learn how a modem works for example, but parts of it are free and GPLed.
(apologies for not reading the source properly),
-- Jamie
Take a look at the very large number of ".dsp" files. These are binary only files. They contain all of the difficult modem algorithms.
The GPL specifies that the code must be in "the preferred form for editing", which is long for "the source code". I assure you that binary.dsp files aren't the source code.
The tar file includes the GPL in the usual "COPYING" file, but none of the driver source files refer to it. Neither does the documentation. In other words, it's a tar file which happens to contain a copy of the GPL text.
In summary, none of the source code is GPLed, and all the difficult modem algorithms are binary only.
Thanks for the helpful driver IBM, but don't pretend this is free software. BTW, there have been half-binary, half-source drivers for Lucent modems for a while now, and several other manufacturers too.
-- Jamie
The LGPL does permit static linking. In fact it makes no references to dynamic linking at all.
If a statically linked application is distributed without source, and is linked with an LGPL library then the distributor must more or less do this (consult section 6 for precision):
(a) Provide source code for the LGPL portion
(b) Provide object files (just one will do) for the rest of the application such that the user can modify the LGPL part and recreate the application.
The easiest way to do (b) is dynamic linkage, but it is possible to do so statically as well. (b) is an important freedom that perhaps you had forgotten. The LGPL does not just protect your right to receive source code for some library that an application happens to use. It protects your right to change the LGPL'd part of the application.
If you wish to make it clear that static linking is allowed, I suggest you say "contrary to popular belief, static linking of my library with closed source code is allowed; please consult section 6 of the LGPL for details".
Oh, and how do you propose to pay for your open source patents?
The EU are right on the ball with this, referring to Open Source. Open Source projects have money, from IBM etc.; they can pay for patents, which suits the Vested Interests just fine.
It leaves out every kind of Free however. Tough.
I was talking to someone from WIPO yesterday about the importance of supporting people like me: free software programmers. Small inventors (in effect) who do not want to make pots of cash through monopolising our inventions. I prefer other ways to make pots of cash.
The person from WIPO really believed that WIPO's work towards easier world-wide patents will help the small inventor. Sometimes true, for those who want to make pots of cash through a monopoly on an idea. But for me? They take away my freedoms and give me what I don't want in return.
We must fight for our intellectual property rights. I.e. the right to think and create independently, and to freely share our thoughts and creations. That right is never really taken away, but there's a big difference between world-wide agreements to permit it, and world-wide agreements which punish you for it.
Even if the world's governments, economic systems and means of administering "justice" change for the better, agreements like the international patent treaties have a powerful long-term effect that will take a long time to reverse. Because everyone will have to agree to undo an unfortunate promise they made earlier. It's reversible, but difficult and much pain is to be had. Much better to avoid the mistake in the first place.
Dearest EU, your economy and quality of life are developing very well without software patents. You do not have to emulate the US of A to attain what you see as its successes. You can do it yourselves, as you are doing already. There's a great deal of strength, wisdom and heart among your members. And a great deal of good, lucrative technology is blossoming right now, within the EU's tradition of technological collaboration. Take a look at your own successes. They are where your strength lies. Enjoy.
3. Just think about all the single parents. Their children (not all are single because the other parent want nothing to do with their kids)
face the fact every day that their other parent "don't love them" and want nothing to do with them.
It does happen.
But never forget that sometimes the other parents do love the children, lots, and wants a lot to do with them but the guardian parent won't allow it. Or sometimes both parents simply agree that they're unhappy living together and, despite their love for their children, they are all better off if one parent leaves for elsewhere. A painful split, but one which can work out nicely in the long run.
Unless your 'input' is simply accepting the digital output stream (and not the analog signal generated by the output), the
watermark will probably be lost - if the watermark is inaudible, I can't imagine that it would survive the
digital->analog->digital conversion.
Shannon proved a long time ago that you can encode information, reliably, in an arbitrarily noisy channel. The noisier the channel, the less information you can encode in it.
This means that no matter how crappy your audio signal, if you want to encode say a 1024 bit number in it reliably despite D->A->D conversion and other things which introduce noise, you can do that. It might take a 10 second sample to completely encode all 1024 bits at inaudible noise levels.
Fuck with the analog in some way
(for example, by adding a known signal to it) that will foul up the watermark-detection, then subtract that known signal
back out of the "clean" digital data you recorded.
Watermarks are designed to be resistant to as much "fucking" as possible. Bad watermarks aren't very fuck-resistant, good ones are.
You don't need to use inaudible frequencies for a watermark, so filtering on frequency won't remove the watermark. You don't need good quality reproduction. Introducing lots of noise (white, pink etc.) of various kinds reduces the information density of the watermark, but that just means a longer time sample is required to detect the watermark (for a given confidence level).
Superb audio compression would remove any watermark (by definition, it's an inaudible signal so should not be stored in a compressed file). However, we don't have perfect compression which makes this a battle between the codec people and the watermark people.
Finally, to rub in how difficult it could get, the watermark is a form of steganography. Some kinds of watermark cannot be detected (that is, distinguished from noise-like signals) without knowing the right key. Some watermarks are very difficult to remove without knowing the right key.
Galeon is a derived work of some other GPL software, so GPL _does_ apply to it. It is also derived from Mozilla, so MPL applies to it.
The combination of both licenses means a compiled version of Galeon cannot be legally distributed. You simply don't have the permission of the authors of the code which Galeon is based on.
He died exactly 2 weeks ago. Spooky! Search for "Peter Tripp" in here. It includes a link to his recent obituary. He had an ongoing career after the 200 hour experiment, so he probably wasn't a vegetable as one poster suggests. Here's another nice article which refers to a couple of long sleep deprivation experiments including Peter Tripp's. Apparently there were no long term side effects, but the short term effects were quite severe. One night's sleep is all it takes to recover. From my own experience, I've found that sleeping too much definitely causes loss of mental ability. I don't get much coding done until late at night after being awake most of the day, when I'm already feeling tired. It's annoying as I want to rest but that's when I get stuff done. On the other hand, communication with co-workers is often more effective earlier in the day. I've found my dark areas under the eyes tend to disappear when I get up early, not late. That really surprised me. I take that as one indicator of physical health, so now I'm not afraid to get up and feel tired when it seems like a good idea: tired does not necessarily mean I need rest. But I'm lazy so I tend to lie in anyway.:-) After a very long session of staying awake, one night is not quite enough to back to "normal". About 4 nights does the trick. But, "normal" is not my most alert, effective or communicative. enjoy, -- Jamie
DAT hasn't been reliable in my experience. I found corruption in the middle of one after a few months. Sure it might have been a dud, but then so might your backup tape... And that was with a supposedly high quality HP drive.
In my experience, CD-R is about similarly safe. I found corruption on one of those once, it was a Linux distro in fact. Maybe it wasn't the medium at fault in that case. enjoy, - Jamie
One of God's web sites is godchannel.com, where the contents are dictated by God personally... so it is written. There's a section from the Mother too for those who are fed up with the "Heavenly Father" angle. It's an interesting read. Metaphysics, vision, God's latest plan, and advice on seeking the light within yourself. I found God's advice there resonant with my earlier inner experiences, but the.com domain and the promotion of certain author's books, and not others which seem equally relevant, leave me just a touch suspicious of the site owners' intentions... Enjoy... -- Jamie
You're right, (hangs head in shame...). ;-)
I had a nagging feeling when I wrote the article
Ah well, at least I managed to explain some of the differences between mmap-write and sendfile.
Thanks,
-- Jamie
True zerocopy has certain hardware and driver requirements. These are the network drivers in linux 2.5.9 which support zerocopy TCP: 3c59x, acenic, sunhme, 8139cp, e100, ns8320, starfire, via-rhine, sungem, e1000, 8139too, tg. (Disclaimer: Not all cards supported by those drivers necessarily support full zero copy). That's from grepping for the NETIF_F_SG and at least one of the NETIF_F_(IP|NO|HW)_CSUM flags.
In Linux, zerocopy is performed using the sendfile(2) system call, rather than writing to a socket from a memory-mapped file, as you are meant to do with the new BSD code. Although the mmap method is a neat way to make a few existing programs faster, it is less efficient than the sendfile() method, to some degree, and certainly more complicated to implement.
A write-from-mmap implementation has to provide a certain allowances for user space behaviour. Although it's advised not to touch the pages from user space, allowance for this basically require the OS to "pin" pages, either by modifying page tables which implies TLB and page walking cost (if the pages are actually mapped, which they probably are not in a Samba/www/ftp server), or by at least pinning the underlying page cache pages in case someone does a write() to the mapped file. sendfile() does not require the pages to be pinned, because it provides different guarantees about which data is transmitted if the data is being modified concurrently.
Another nice thing about sendfile() is that it's quite fast even for small files. The overhead of calling mmap() and then munmap() may outweigh the copying time for a small transmission. Basically, why bother with mmap/write/munmap when you can just do a sendfile, which doesn't require the kernel to jump through hoops to decode what you meant.
Well, I don't know if it makes much difference in performance if you only mmap() a file without referencing the pages from user space, and write it to a socket. We'll have to wait for the numbers.
But there is another great thing about sendfile! You can use it to transmit user-space generated data, such as HTTP headers, too. This is done by memory-mapping a shared file (such as a pure virtual memory "tmpfs" file, but you can use a real disk file too). Then you can write to that mapped memory from user space, and call sendfile() to transmit what you have just generated.
You can do what I just described, with a mapped, shared file, using the new BSD zerocopy patches too. If using sendfile(), the weaker concurrency guarantees of sendfile() vs. write() mean it is your responsibility to not modify the data until you are sure it's been received at the far end. In some ways user space has more responsibility, to be carefully manage the data pool with this method of using sendfile() for program-generated data, than using BSD-style write(). On the other hand, that's exactly why the BSD kernel must do more work of pinning pages, and in this mode of usage there is definitely TLB flushing cost and cross-CPU synchronisation cost, so if you are really crazy for performance, sendfile() may just have the edge. (Well I expect so anyway, I haven't done performance comparisons).
By the way, write() from memory-mapped files has been discussed among linux kernel developers several times in the past, and each time the idea lost due to the feeling that page table manipulation is not that cheap (especially not on SMP), and now that we have sendfile... Well, if you were writing a really high performance user space server, you'd use sendfile anyway so writing from mmap becomes a bit moot.
Finally, zerocopy UDP is not implemented in linux at present as far as I know, but some gory details were discussed recently on the kernel list so it is sure to arrive quite soon. The difficult infrastructure (drivers, page-referencing skbuffs) which is used by the zerocopy TCP implementation has been part of the 2.4 kernel since 2.4.4 (more than 1 year ago) and I believe it has been thoroughly tested since then.
Enjoy,
-- Jamie Lokier
(BTW, I am not a legal advisor. This is my understanding of the GPL).
If you are including other people's GPL'd source code in a program which you distribute, then you must abide by the terms of that license. Section 3 of the GPL is precise enough to disallow scrambling the source code:
There is nothing to stop you changing all the variable names, or the style of someone else's code. However, if you distribute a GPL'd binary then the source you distribute with it must be the source that you prefer to use for modifying the program yourself. You may be called upon to prove this in a dispute.
For reference, section 3:
Absolutely no way I'm installing any software on my computers that comes with the conditions below:
The point of the GPL is to prevent *hoarding* of code, in order to guarantee everyone who has a use for the code certain freedoms to use it.
IMHO it's a shame that this inevitably leads to license conflicts with other kinds of free software. But there is no way to prevent hoarding without also preventing some other uses. Ah well.
Although you have a valid point, you need to realize that this offer comes together with a bold move by the government to put everything on the internet; there are a lot of projects going on to make sure that in a few years time, it is possible to do everything online, from filling in taxes to paying a parking ticket. So a lot of people do not have a good use for a cheapo PC at this time, but that will change when all that stuff gets online (you need to interact with the government quite frequently in here) -- and when they only go get one at that time they may find themselves seriously lagging behind in skills compared to those who get a PC now.
And if all those computers are running Windows XP, the government service web sites are free to require use of a Microsoft browser. Which means that if you'd choose to uninstall the Windows XP and switch to something else, so that you can learn more about how computers work, you won't have that option. So much for empowering the poor, eh?
It's a nice way to guarantee that Digital Rights Management stuff (i.e. to prevent you from "unauthorised playing" of movies), without actually making it law, too.
One day, I incorporate 1/4 of a Free software package's code into my new program, so I need to cut and paste, say, 1/4 of the documentation for the package to make the documentation for my program.
At which point, having to send changes to parts of the documentation for my program back to the authors of documentation for a different program is a waste of everybody's time .
-- Jamie
It depends on the kind of compression. With V.42bis, you are probably right.
There's a school of thought that says: Compressing closer to the modem stack gives you marginally better real time response, provided the compression itself is just as good. This is because you can postpone decisions about where to place packet boundaries, and how exactly to compress the last symbols, until just before a packet must be emitted. In fact, with the V.42 protocol, you can defer selecting the packet boundaries until you're in the middle of a packet.
This would be a win with, for example, a Bzip2 style of compression (block transform), if you had the choice between doing the transform in the IP layer or doing it at the last possible moment in the link layer.
I agree that for V.42bis/MNP5/V.44, given the possibility of PPP compression, it's probably better to use just PPP compression. I'd like to see measurements though.
So you like specialized hardware? This project helps towards the goal of specialized Free (as in speech) Hardware. Just because it works on an Athlon doesn't mean it can't be ported to a GnuDSP, or even a GnuFPGA with good tools.
The patents are a real problem. I'm not sure what to do about them for, say, the commercial distributions, but I don't see them having a serious leg to stand on w.r.t. freely distributed code for personal experimentation/education purposes. It's the user's problem to verify that they have the appropriate licenses, particularly as 99.9% of users are likely to have those licenses. It's perhaps the developers' problem to inform the users. As far as I know. (I would like a proper legal opinion though).
:-) and enjoy,
-- Jamie
When you apply the software modem to ISDN, you get:
enjoy,
-- Jamie
Interesting; I did not see this second message from Alex. Have I been unsubscribed from the list over the weekend, I wonder?
I'm going to answer a few questions that have been raised, and a few that haven't.
Is anybody working on the code?
Fabrice started first. Unfortunately, he has been quiet for a very long time, and I have no idea if Fabrice has done further work on the modem code. I hope he is still well and healthy.
Meanwhile, I have been secretly still working on my code base (that's the one at tantalophile) all this time. It has been an on and off affair, and I've found it difficult to find the time, energy or focus what with the day job and other projects. I keep foolishly trying to improve on the standard algorithms ;-) Nevertheless, bugs have been fixed, features added, tests done, signals are processed better than ever and I have a nice set of graphs showing simulated error performance of the V.34 core under various conditions.
In other words, there's a long way to go and please, nobody hold their breath, but there has been substantial progress and it is not on the tantalophile web site. So don't slashdot it, thanks :-) I'm making no promises about when my new material will appear, but I do promise it will be announced on the linmodems mailing list.
About the bounty
It's a bit of a nice surprise to see that offered. I'll be contacting Alex, but to be honest I am motivated to complete the project anyway. I don't want funding to dictate the goals of the project (which should be educational and of high quality, IMHO, as well as functional), although some influence would be understandable. It is likely to make a difference to the schedule though.
Legal clarification and/or commercially backed negotiation on the patent issue would be invaluable, and help with testing is also very valuable.
I didn't respond to the original $5000 request because it is not a lot of money. Considering the large amount of time, effort and to some extent resources already spent on the project, as an estimate for the remaining work, I would certainly not accept a commercial contract at that sort of rate. $20000 is rather more interesting, but I think Alex's request for V.90 is unrealistic if he wants it on a short timescale.
One thing that would be a bit upsetting is if all my work were quickly overshadowed by someone else, suddenly motivated by cash, throwing something together. But I cannot complain as I haven't exactly been speeding ahead or keeping with the community on this. I know how the Hurd feels ;-)
Standards compliance, approval, and "homologation"
This is quite hard, because anyone can modify the code and thereby break any certification of the code.
Different countries have different standards. There are differences in the energy that can be emitted, both the peak instantaneous energy and a longer term average are limited. And you don't always want to max out the energy anyway, as you're avoiding distortion.
The relationship between voltage and current is not the same everywhere. Dialing tones, engaged tones and so on vary. V.90 coding varies because the USA operates at a lower digital bit rate than most of Europe.
Some people have said that it is the hardware which is subject to regulation. This is not true. I believe there is a certain certification level for the hardware itself, for avoiding excessive energy input, making sure the hardware doesn't go up in flames when receiving the 100V ring pulses or a lightning bolt, that the impedance is matched, and so on.
However, it is (theoretically) necessary to certify the software as well for many reasons. A good example: by modifying the software, you can transmit more energy on a USA telephone line, using a USA modem, than is permitted by federal regulations. That excessive energy is considered to potentially interfere with other people's telephone calls. So, you do have to get the software right.
Fortunately we have a good example of certification in the Linux kernel. Some versions of the Linux ISDN code are certified for use on the German telephone networks, I believe. The source code is checksummed. I note with interest that it's the source that's certified, and not the binary (so the beurocracy is ignoring bugs in the compiler or the rest of the kernel).
For myself, I am very keen to write code which certainly does conform to all the known requirements. I don't feel comfortable hacking together some "it seems to work" code of this kind and releasing it like that. It's partly a reputation thing, and partly a responsibility thing.
On patents
Yes, there are many patents. Unfortunately the detailed patent situation is unknown. It is possible that the patents don't apply to software implementations in most countries, but we don't know to what extent and where each patent applies.
We don't even know which patents apply! However, there is an online list at the ITU which may be helpful.
This is hopefully an area in which Alex Pilosov and his (possibly) commercial backing can help in a big way.
I am of the opinion that users have, in general, already paid for their modems and so they should already have permission to use the techniques. It seems to be the case that software modem drivers for Windows are downloaded and installed with no attention paid to these matters, so it should not be any more of an issue for Free Software. It would be good to know for sure.
The developing world
Telephone line driver chips are cheap! For the developing world, getting an internet connection over crappy copper would be a wonderful achievement, and with full access to a software modem, you could cobble the modems together from parts.
For this reason I think it is important that the softmodem works well over poor lines as well as good ones. And yes, I would love to code "workarounds" for when the standard algorithms don't perform well on Nepalese copper lines, or wherever. It would have to be a special variant of the code, for the regulatory reasons stated earlier, but it's a lovely thought.
Is it still worth writing a software modem in order to use "winmodems" on Linux?
The motivation has certainly waned, now that many previously windows-only modems are now supported on Linux by binary-only drivers from the manufacturers. Of course, you cannot use them if you're using the wrong kernel, or SMP, or if you have more than one modem, if you don't permit binary-only drivers, if you are using an Alpha or a PPC-based iMac, or if you want to run any-BSD. But hey, a lot of users are happy enough now, so that does remove some of the motivation for writing the code.
Which leaves the educational aspect. The interior of a modern modem is not well documented, even in books about signal processing. To be sure, many of the classic algorithms are very well written up, but the details as they apply to modern modem standards are not, and there are some algorithms which V.34 and V.90 clearly require which I have yet to find any information about. (Welcome to re-inventing the wheel, but it is fun!) As Alan Cox once said, the V.90 standard is "semi secret". Read it sometime, if you don't mind paying the relatively modest fee, and you'll see what he means.
Revealing just how a modern modem works, in the form of working code that (I hope) is readable by those who wish to study it, then, is as much a goal for me as getting winmodems working. And it's interesting because I'm still figuring it out myself :-)
Interfacing with the hardware
Several people pointed out, quite correctly, that a software modem won't actually work with any of the hardware "winmodem" devices. This is correct; we need device drivers too, and that is accomplished by reverse engineering the original drivers.
I don't know Alex's exact requirements. He doesn't mention needing PCM drivers -- perhaps he has his own drivers already? But if he requires reverse-engineered PCM drivers as well then that's quite a bit more work.
Progress on that front is being made, by several people, but it is really a separate project. It is worth noting that there's a GPL'd Lucent modem driver that can do PCM. It is actually quite old now. I have faith that the PCM driver part of this problem will be solved by eager contributors if there is a good softmodem to make use of it.
Cheers,
-- Jamie
Reread the article. Jon Katz is not laying the blame on anyone and neither should you. It is not politician's fault if they seem to be focused on the wrong part of the problem: they don't know any better. Politicians have kids, and some of them had unhappy childhoods too, you know? The solution here is to educate and direct the politicians. Give them good advice, good feedback. Help them to see and implement solutions. Make sure they feel good when they do implement solutions. Jon Katz is helping to inform policy makers, and so are you with your diverse opinions.
It's not parent's fault if they are "bad" parents. How many of you really know how to be good parents? Sure, a lot of us here seem to intuitively know the principles of good parenting. But just you try applying your principles when you really, really don't understand why you're kid 20 years younger than you doesn't seem to listen to anything you say to try to help. Most parents do sense when their kids are unhappy, and with some kinds they don't know how to help. They feel like they've tried everything they can think of. Don't blame the parents: that just makes them resent you more. More to the point: it confuses them. They can't see the answers when they, the parents that is, think you hate them. Remember, parents are kids inside too, and for all these troubled children who became happier adults, there are adults who are still as troubled as they were when they were children. If you think you have good parent instincts, apply them: do go and talk to children who near live you. Without offering candy.
You can't blame video games. And you can't blame lack of video games, which you do when you talk about how important it is that the games help you let off aggression. The simple truth is, and everyone knows it, that video games, and violent images especially in entertainment, do program a certain violence thoughts into your mentality. Don't take this as a bad or a good thing! It just is, and brings me to the next point:
Can you blame the perpetrators of crimes? I.e. is it their fault? Some say yes it is their fault and they do not get enough blame. Some say no, they are a product of their awful environment. I say both points of view are right. There is no contradiction. No paradox: in fact the paradox is a clue to look for another way of thinking. Move away from talking of blame.
People, including but not restricted to children, are programmed by their environments, and the things they watch on TV. Minds do have a strong mechanical, habitual nature. And everyone here knows it. Ever played tetris for weeks and then seen tetris figures everywhere you go? Your mind is mechanical; don't confuse it with you. Trust me, the tetris effect is the tip of a vast iceberg of habitual thought and emotion processes that most of us do not study in ourselves. We should, as the most frightening things are not "really" frightening when you know why you're reacting that way.
Back to environment. People are made resentful by the things that happen to them. Yet people including children are responsible for the TV they choose to watch. Often, they could do self-defence and other courses which would help them tackle bullies. They could talk to the other kids who are even more frightened and unhappy than they. You see, even children can be "blamed" for their own environmental programming, because they are presented with choices that they are afraid to take. Like taking a martial arts course, or talking to other strange kids, might be too scary, even if it's a patently good idea. Yet you cannot blame anyone for not doing something because they are too scared. Well, you can if you like but I assure you it does not help them to be less scared.
Do you blame the TV or the people? No, you should aim to teach the people to know how they are affected. There is nothing wrong with watching violent or playing violent games. But it does affect your habitual thoughts and emotions. So learn to be aware of the effects, and decide how to program yourself. This is the importance of know thyself. Well, one importance.
By the way, self-awareness lessens or enhances the effect of environmental programming on yourself, whatever you choose from situation to situation. This is the secret to being simultaneously free to do as you please while being in charge of the environment's programming of your own mind. This is why it's ok to play violent games, to love Marilyn Manson etc ;). Those here who "play games and they don't make me violent" are proof of this.
Everything outside is some kind of bully, until you know how to deal with it. And then it isn't -- it's your friend, or at least an amusing sideline.
Laying of blame really is not the solution. It is helping, because as one thing and the next thing are "blamed", they are scrutinised. Every bit of the struggle helps. But it's maybe not the most efficient route to freedom and happiness.
As someone wiser than me said: we are interested in solutions, not problems. Blame is being interested in problems.
To a person who is in the verge of killing themselves, or committing some nasty act towards others, just knowing that life does get better is a wonderful gift. You've seen it among the replies here already. Lives are transformed by this simple knowledge. This is a far more beautiful solution than anything that comes from blame, blame, blame.
Just don't use that as an exuse to pretend that violent, and indeed other depressing images don't have a mental effect. They sure do. On everyone. The secret of happiness is remembering to put this where it doesn't hurt.
Oh god, I could go on and on :-) Remember even nutcases like me were unhappy children once :-)
thanks for reading, btw life really does get lots better as you get older,-- Jamie
Today, programs and algorithms written down in academic publications are presently not available for all to use.
For example, go and look up the many papers on register colouring in a compiler. I believe you cannot use all some documented algorithms due to patents (which expire soon, fortunately).
Look up text in international standards like ITU-T V.8bis for modems, and you find a stern warning that implementing the standard may infringe on some patents (although you are not told which ones or how to find out).
The RSA encryption algorithm was documented in many papers, but until recently you weren't free to use it.
Take a look at the book "Numerical Recipes in C". It's a nice book describing numerical algorithms, but you are warned that the example programs are copyright the publisher, and you cannot just type them in and use them as-is. This leaves a questionable grey area, because you can presumably write your own code modelled on the code presented in the book.
In a world without copyright, all these things which are published in books and papers would be free for all to use.
No, it's a Field Programmable Gate Array
Oops! The driver source is GPLed, it just doesn't refer to the "COPYING" file like I'd incorrectly remembered in the traditional GPL copyright template. Ahem. The .dsp files, containing the modem algorithms, are still binary only though. The whole driver is still not free software. You don't have the freedom to port it to other hardware, run it over a sound card or a ham radio, modify the signalling methods, or study the DSP code to learn how a modem works for example, but parts of it are free and GPLed.
(apologies for not reading the source properly),
-- Jamie
Take a look at the very large number of ".dsp" files. These are binary only files. They contain all of the difficult modem algorithms. The GPL specifies that the code must be in "the preferred form for editing", which is long for "the source code". I assure you that binary .dsp files aren't the source code.
The tar file includes the GPL in the usual "COPYING" file, but none of the driver source files refer to it. Neither does the documentation. In other words, it's a tar file which happens to contain a copy of the GPL text.
In summary, none of the source code is GPLed, and all the difficult modem algorithms are binary only.
Thanks for the helpful driver IBM, but don't pretend this is free software. BTW, there have been half-binary, half-source drivers for Lucent modems for a while now, and several other manufacturers too.
-- Jamie
The LGPL does permit static linking. In fact it makes no references to dynamic linking at all.
If a statically linked application is distributed without source, and is linked with an LGPL library then the distributor must more or less do this (consult section 6 for precision):
(a) Provide source code for the LGPL portion
(b) Provide object files (just one will do) for the rest of the application such that the user can modify the LGPL part and recreate the application.
The easiest way to do (b) is dynamic linkage, but it is possible to do so statically as well. (b) is an important freedom that perhaps you had forgotten. The LGPL does not just protect your right to receive source code for some library that an application happens to use. It protects your right to change the LGPL'd part of the application.
If you wish to make it clear that static linking is allowed, I suggest you say "contrary to popular belief, static linking of my library with closed source code is allowed; please consult section 6 of the LGPL for details".
Oh, and how do you propose to pay for your open source patents?
The EU are right on the ball with this, referring to Open Source. Open Source projects have money, from IBM etc.; they can pay for patents, which suits the Vested Interests just fine.
It leaves out every kind of Free however. Tough.
I was talking to someone from WIPO yesterday about the importance of supporting people like me: free software programmers. Small inventors (in effect) who do not want to make pots of cash through monopolising our inventions. I prefer other ways to make pots of cash.
The person from WIPO really believed that WIPO's work towards easier world-wide patents will help the small inventor. Sometimes true, for those who want to make pots of cash through a monopoly on an idea. But for me? They take away my freedoms and give me what I don't want in return.
We must fight for our intellectual property rights. I.e. the right to think and create independently, and to freely share our thoughts and creations. That right is never really taken away, but there's a big difference between world-wide agreements to permit it, and world-wide agreements which punish you for it.
Even if the world's governments, economic systems and means of administering "justice" change for the better, agreements like the international patent treaties have a powerful long-term effect that will take a long time to reverse. Because everyone will have to agree to undo an unfortunate promise they made earlier. It's reversible, but difficult and much pain is to be had. Much better to avoid the mistake in the first place.
Dearest EU, your economy and quality of life are developing very well without software patents. You do not have to emulate the US of A to attain what you see as its successes. You can do it yourselves, as you are doing already. There's a great deal of strength, wisdom and heart among your members. And a great deal of good, lucrative technology is blossoming right now, within the EU's tradition of technological collaboration. Take a look at your own successes. They are where your strength lies. Enjoy.
Example 108 MHz - you have a maximum of 108Mbps
I see sir, would you kindly explain how a modem gets 33.6kbps down a 1959 Hz carrier on a phone line with ~4kHz bandwidth? Thanks.
3. Just think about all the single parents. Their children (not all are single because the other parent want nothing to do with their kids) face the fact every day that their other parent "don't love them" and want nothing to do with them.
It does happen.
But never forget that sometimes the other parents do love the children, lots, and wants a lot to do with them but the guardian parent won't allow it. Or sometimes both parents simply agree that they're unhappy living together and, despite their love for their children, they are all better off if one parent leaves for elsewhere. A painful split, but one which can work out nicely in the long run.
Unless your 'input' is simply accepting the digital output stream (and not the analog signal generated by the output), the watermark will probably be lost - if the watermark is inaudible, I can't imagine that it would survive the digital->analog->digital conversion.
Shannon proved a long time ago that you can encode information, reliably, in an arbitrarily noisy channel. The noisier the channel, the less information you can encode in it.
This means that no matter how crappy your audio signal, if you want to encode say a 1024 bit number in it reliably despite D->A->D conversion and other things which introduce noise, you can do that. It might take a 10 second sample to completely encode all 1024 bits at inaudible noise levels.
Fuck with the analog in some way (for example, by adding a known signal to it) that will foul up the watermark-detection, then subtract that known signal back out of the "clean" digital data you recorded.
Watermarks are designed to be resistant to as much "fucking" as possible. Bad watermarks aren't very fuck-resistant, good ones are.
You don't need to use inaudible frequencies for a watermark, so filtering on frequency won't remove the watermark. You don't need good quality reproduction. Introducing lots of noise (white, pink etc.) of various kinds reduces the information density of the watermark, but that just means a longer time sample is required to detect the watermark (for a given confidence level).
Superb audio compression would remove any watermark (by definition, it's an inaudible signal so should not be stored in a compressed file). However, we don't have perfect compression which makes this a battle between the codec people and the watermark people.
Finally, to rub in how difficult it could get, the watermark is a form of steganography. Some kinds of watermark cannot be detected (that is, distinguished from noise-like signals) without knowing the right key. Some watermarks are very difficult to remove without knowing the right key.Galeon is a derived work of some other GPL software, so GPL _does_ apply to it. It is also derived from Mozilla, so MPL applies to it.
The combination of both licenses means a compiled version of Galeon cannot be legally distributed. You simply don't have the permission of the authors of the code which Galeon is based on.
He died exactly 2 weeks ago. Spooky! Search for "Peter Tripp" in here. It includes a link to his recent obituary. He had an ongoing career after the 200 hour experiment, so he probably wasn't a vegetable as one poster suggests. Here's another nice article which refers to a couple of long sleep deprivation experiments including Peter Tripp's. Apparently there were no long term side effects, but the short term effects were quite severe. One night's sleep is all it takes to recover. From my own experience, I've found that sleeping too much definitely causes loss of mental ability. I don't get much coding done until late at night after being awake most of the day, when I'm already feeling tired. It's annoying as I want to rest but that's when I get stuff done. On the other hand, communication with co-workers is often more effective earlier in the day. I've found my dark areas under the eyes tend to disappear when I get up early, not late. That really surprised me. I take that as one indicator of physical health, so now I'm not afraid to get up and feel tired when it seems like a good idea: tired does not necessarily mean I need rest. But I'm lazy so I tend to lie in anyway. :-) After a very long session of staying awake, one night is not quite enough to back to "normal". About 4 nights does the trick. But, "normal" is not my most alert, effective or communicative. enjoy,
-- Jamie
DAT hasn't been reliable in my experience. I found corruption in the middle of one after a few months. Sure it might have been a dud, but then so might your backup tape... And that was with a supposedly high quality HP drive.
In my experience, CD-R is about similarly safe. I found corruption on one of those once, it was a Linux distro in fact. Maybe it wasn't the medium at fault in that case. enjoy,- Jamie
One of God's web sites is godchannel.com, where the contents are dictated by God personally... so it is written. There's a section from the Mother too for those who are fed up with the "Heavenly Father" angle. It's an interesting read. Metaphysics, vision, God's latest plan, and advice on seeking the light within yourself. I found God's advice there resonant with my earlier inner experiences, but the .com domain and the promotion of certain author's books, and not others which seem equally relevant, leave me just a touch suspicious of the site owners' intentions... Enjoy... -- Jamie