That report's logic is fallacious. Consider the case of case of two similar individuals: one who lives to a to a bit less than 65 in 1940, and another who lives a bit past 65 in 1990. People whose life expectencies have increased from below 65 to just above 65 will reduce "average life expectancy of people at age 65" just by their living past 65. Their negative life expectancy past 65 in 1940 was not counted, but there marginally positive life expectancy past 65 in 1990 is.
Clarification
on
The Euro
·
· Score: 3, Insightful
Just to clarify the parent poster's point, it is theoretically possible for everyone in a country to reduce all of their salaries and government benefits to compensate for their
decreasing productivity. However, it is generally impractical to get everyone to agree to do this in sync, while it is trivial if not automatic if that country has a separate currency.
The situation in Argentina is a bit different, because part of the problem is that the government claimed to back its currency with more US dollars than they actually currently have.
The question of porting a non-unix MacOS X application to Linux makes me wonder what the current state of MacOS emulation under Linux is.
I see that Basilisk is apparently a
GPL'ed 68k Mac emulator
under relatively active development, and
that the proprietary
executor
is still available, along with Carbonless Copies from the same company.
Also, a couple of others
are discussed on
emulators.com.
The technique is called
Forward Error Correction. I don't know much about it, but I know that you can do things like break up a file of N*B bytes into 2N blocks of B bytes each and then be able to reconstruct the file from any N of the 2N blocks. The GPL'ed Mojonation system uses it, if I recall correctly, to distribute each 32kB chunk of data into eight 8kB blocks allowing reonstruction from any four of them.
I would love to see an affordable TFT monitor kit for the 2048x1536 20.8 inch viewable 300:1 contrast raio
IBM ITQX20 TFT monitor described at
http://www-6.ibm.com/jp/oemj/lcd/itqx20.htm.
The display costed $2k or less to OEM's a year ago, but the companies that build monitors from it charge ~$6k for the monitor with video card. That's a big mark-up for a dual LVDS video card (digital end-to-end), a power supply and some plastic.
I think there is still some additional programming productivity to be had from a bigger monitors, so I think it would be an appealing purchase for software devopers if you could get it down to ~$2k (hopefully due to volume).
[...] even without faster than light travel (the idea is exponential growth -- we send two colonies, then they)
Just to be pedantic, let me point out that this is not exponential (2**n) growth, because it is limited by the speed of light. Instead, there would be no more than cubic growth (n*n*n), because the rate of growth would be limited to the size of a sphere expanding at the speed of light from where this intelligent species originated.
The numbers that you mention already accomodate this, but I thought this subtlety might be of interest to slashdot readers anyhow.
If these unnamed businesses that find even the LGPL onerous are legitimate, they should have no problem paying you serious money to switch to the new BSD terms. They support the proprietary model, and you've worked hard on this project.
If they do not pay, then, your sticking with LGPL will help the development of the core free version (although perhaps hindering proprietary forks) by ensuring that future enhancements to libFLAC are incorporated, which is particularly important in the case of something that is likely to be incrementally improved by tinkering or where standardization and interoperability may be affect adoption.
Although I personally prefer LGPL'ed libraries, I would be remiss in not mentioning that, by similar argument, you might could go further and set up a "FLAC consortium" that companies would pay a small amount of money to in order go get the right to use libFLAC under something like LGPL (but which would not conflict with the requirement to pay dues).
Comdex is not the first major computer trade show to ban cameras. At LinuxWorld in San Francisco in August(?), I watched a show staff member enforce it against some random attendee.
Personally, I think a ban on cameras at a trade show gives the impression of an industry trying to avoid accountability to its would-be buyers. I would much prefer exhibiting at trade shows that allow cameras.
I am posting this from a notebook computer that has all partitions encrypted except for a boot partition at the front of the disk.
The kernel boots an initial ramdisk with an/sbin/init script that does essentially the following, using cryptoapi, the successor to the linux "kerneli" patches.
This should work with any disk file system, not just ext2.
I have been using this arrangement for several months now on a couple of computers, the slowest of which is a Kapok 1100M that uses a 233MHz Pentium II process and, I believe, PC-66 SDRAM. On that computer, the change in interactive responsiveness is hard to notice, but it is noticible for disk intensive activities. I have not timed it, but I think that big rsync runs are at least a factor of two slower.
I do not run swapping on these computers, as
I've seen claims that there are more potential deadlocks when attempting to swap to an encrypted partition than when attempting to swap to an unencrypted partition.
1. There is no need to build a mechanical autoloader. IDE controllers and removable drive bays are cheap, less than $25 per drive, making them much cheaper than a robotic loader, with greater reliability and response time to boot. IDE drives can be spun down when they've been idle for a while, so electricity consumption should be similar.
2. I believe that Linux IDE does not currently support hot swapping of drives, although the PCMCIA drives do support removal of an entire IDE controller, which is what happens when you remove a CompactFlash card.
3. My understanding is that hard drives are not hermetically sealed but rather have air filters similar to what you stuff at the end of a cigarette is made of. I believe that when hard drives are not in use, they can accumulate dust internally and are more likely to have problems. You may also have problems with their greater sensitivity to being dropped and to statically electricity. So, you may want to store them in sealed conductive bags.
4. In my humble opinion, I think you have a good idea. I believe that, disk-based backups are much more valuable to an organization because they're easy enough to use that people will save time by doing minor recovery tasks. In comparison, with tape backups, the effort of doing a restore can be so much that people will often opt to spend an hour regenerating their previous work from scratch instead.
At LinuxWorld in San Francisco, Geoff Harrison (sp?), co-author of the Enlightenment window manager, talked about text/speech conversion. If I recall his talk correctly, most proprietary voice recognition software is derived from the free sphinx system developed at Carnegie-Mellon University, which also has a sourceforge area. The web page at CMU talks about a sphinx3 program that is slower but more accurate, which sounds like a better fit for transcribing a previously recorded interview, but I did not see a link to the source code for it.
Geoff's employer, Cepstral, also claims to have
released some related software under "relatively liberal" permissions. (Sorry, I could not find any download links or texts of the corresponding copying permissions.)
The sphinx2 copying permissions have an advertising restriction similar to the one that made the old BSD copying conditions
GPL incompatible but "free" in the opinion of the Free Software Foundation. I do not know about the situtation with sphinx, sphinx3 or any Cepstral contributions.
I don't know what the law is in Canada about 802.11b wireless ethernet, but people do make line of sight point-to-point 802.11b links with dish antennas on both ends that are as long as 20+ miles. I understand that Linksys WAP11 access point (US$200) can be configured as a repeater, as can some Cisco Aeronet unit that costs US$1k. Of course, when you include the antennas, housing, professional design and installation, the cost of making these repeater stations will go way up, but still nowhere near US$80k.
If you're talking about spinlocks and you're running on a single CPU machine (even with an SMP kernel), the kernel never blocks on a spinlock, because there is never spinlock contention (except for a kernel locking bug, where the kernel will lock up hard at that point). The overhead of the checking the spinlocks is also very small (nanoseconds on that single CPU system, especially since there is no cache snooping). So, the delays that are long enough to deplete sound buffers are going to occur because the granularity of time slices between processes is too long, not because of lock contention.
With HZ=100, the timer tick is 1/100th of a second (ten milliseconds), and any process running at a CPU priority of nice 0 (the standard), nice -1, nice -2 or nice -3 will get five ticks (see the definition of TICK_SCALE in kernel/sched.c), so each time slice will be 50ms, which begins to approach the buffer size of sound cards when you have a few runnable processes, and is already much longer than video frame rates.
Re:Check out the Preemptible Kernel patches...
on
Kernel 2.4.11 Released
·
· Score: 4, Insightful
For things like playing buffered video and sound,
where you just need to get the CPU every few milliseconds, I would think that the system call code paths are not so long that you really need a preemtable kernel. I would expect that it would be enough to just change the time quantum from 1/100th of a second to, say, 1/5000th, by replacing the "#define HZ 100" in include/asm/param.h to "#define HZ 5000". I have not tried this, but this sort of thing has been discussed on the linux-kernel mailing list. One person there reported that doing this prevented his Palm cradle to no longer be able to sync, so be warned that this seems to trip at least one bug.
As someone who has only looked through the preemtable system call patch and never tried it, my impression is that while it may be great, I expect its design to change a bit. Right now, under this patch, you build the kernel with basically a fixed number of fake CPU's that basically make your computer look like it has more CPU's than it does. The kernel being preempted basically causes the old kernel's state to become associated with one of these fake CPU's and then the preempting context takes over a real CPU. [I'm really not doing justice to code in this oversimplified and possibly misinformed description.]
In the future, I would hope that the need for a fixed number of fake CPU's would disappear and the "old fashioned" way of doing context switching would also disappear when the preemtable kernel option is selected. In other words, that would be the only way that context switching would normally occur, rather than having two ways of doing the same thing.
I have always regarded the potential for a preemtable kernel as the biggest side benefit of the move to SMP in Linux 2.0, and I'm glad to see people turning it into a reality.
However, maintaining the option of making a non-preemtible kernel may be worthwhile, at least for a uniprocessor kernel, because the preemtible kernel code relies on running an multiprocessing kernel (even on a uniprocessor),
which has a slight performance cost in setting and releasing all those locks that never once experience contention.
It looks like a great product, but I notice a few minor nits:
Vertical refresh rate: 41-56Hz. Since no multiple of 30Hz is available, playback of DVD's will not be as perfectly smooth as it could be. On the other hand, people generally do not run CRT's at a multiple of 30Hz, due to issues of phosphor image persistence and 60Hz AC power in many countries.
26.4 pounds, 7.7 inch depth, 111 Watt power consumption (so it probably has a fan). In terms of lightness, sleakness, power efficiency and quiet, this display is about a third of the way toward a CRT. So, it's not as appealing as a really expensive high tech toy.
Video card is PCI rather than AGP. With 24-bit pixels, the frame buffer is at least 26MB, and a 33MHz 32-bit PCI bus can only tranfer a maximum of 133MB/second, so the entire screen can only be redrawn from scratch at five frames per second. Maybe the PCI card is 66Mhz or 64-bit (probably not).
On the positive side, I wonder if the card that comes with the T220 can be obtained separately at a reasonable price and can drive the ITQX20's digital inputs (the 2048x1536 20.8" TFT display that is in the T210 monitor). Then you could build something for a few thousand dollars that would still be a big step up from the 1600x1024 flat panels.
it IS only a 22inch widescreen. That means it has less image height than a normal 20inch CRT.
If you read the chart at the bottom of the web page describing the T220, you will see that the T220 has a (diagonal) viewable image size of 22.2 inches, or the equivalent of approximately a 24-25 inch CRT, since CRT's are measured by the outside tube dimensions while flat panels are generally measured by actual viewable area.
On the other hand, if you only want viewable image size, you can get some pretty nice projectors or big monitors for a lot less than $16k.
I'd like to see someone create a web database on politicians' voting records on issues relevant within the technical community (ideally with some kind of interface for selecting which issues you care about, and even in which direction). Hopefully, this would help people make more informed decisions, and, just the public knowledge that such a database is being compiled and published might influence legislative decisions a bit.
Anyhow, here is a small start. I would encourage anyone with additional data to post it right here. I'll try to add it to this list, and perhaps someone more ambitious will be able to browse the follow-ups and start a real web database on this.
United States Senate:
CALIFORNIA: Diane Feinstein, Democrat, Bad
- Co-sponsored "Combating Terrorism Act of 2001"
http://www.wired.com/news/politics/0,1283,46852,00.html
o Elected in 1992 (short term), 1994, 2000, 2006
MICHIGAN: Carl(?) Levin, Democrat
+ Argued against "Combating Terrorism Act of 2001"
NEW HAMPSHIRE: Judd Greg, Republican, Bad
- Called for crypto key escrow after World Trade Center bombing
http://www.wired.com/news/politics/0,1283,46816,00.html
o http://www.senate.gov/~gregg/body_about_judd_gregg.html
o Elected in 1998, 2004?
UTAH: Orrin Hatch, Republican, Mixed
+ Suggested mandatory licensing for online music copyrights
- Co-sponsored "Combating Terrorism Act of 2001"
http://www.wired.com/news/politics/0,1283,46852,00.html
o Elected in 1976, 1982, 1988, 1994, 2000?, 2006?
VERMONT: Patrick Leahy, Democrat, Good
+ Argued against "Combating Terrorism Act of 2001"
http://www.wired.com/news/politics/0,1283,46852,00.html
o 1974...1998, 2004?
United States House of Representatives:
Bob Goodlatte, Virginia, 6th District, Republican, Good
+ Co-sponsored lifting of encryption controls
+ Speaking out against encryption controls after World Trade
Center Bombing. http://news.cnet.com/news/0-1005-200-7249721.html
Zoe Lofgren, California, Democrat, 16th District, Good
+ Co-sponsored lifting of encryption controls
We don't need to play defense on this issue. We can play offense.
The increased terrorist attacks underscore the need to strengthen our computer networks with strong unbreakable cryptography. Some well meaning but misguided inviduals may argue that we should weaken our computer infrastructure with back doors to ease law enforcement, but that weakening would create a greater opportunity for terrorists, as it is a virtual certainty that, with so many back door keys, some will fall into the wrong hands.
In foreign policy, we neeed to promote the use of strong cryptography abroad, not only to strengthen the computing infrastructure of free countries, but because strong cryptography in the hands of the citizenry could help undermine oppressive regimes and enable more internal efforts at democratic reform. Since it is from oppressive regimes where terrorism seems to originate most often, making these governments more democratic is likely to be one of the most cost effective ways of reducing the terrorist threat.
We need to pueblicize the idea that the governments of the free world should be actively promoting strong cryptography, both to guard against potential cyber-attack and to reduce terrorism at its source.
Terrorism originates disproprotionately from areas with autocratic governments, such as many arab countries, Afganistan, Iran and Iraq (there are exceptions, like Northern Ireland). To reduce terrorism in the long run, rather than changing our government to look slightly more like the governments that breed terrorism, we should instead try more ardently to change autocratic governments to be more democratic.
Looking back, imagine if we had had the guts in the Soviet-Afghan war to insist on also funding the more democratic elements of the Afghan resistance, against the wishes of Pakistan. Imagine if we had installed a democracy in Kuwait. Imagine if we did more to support democratic forces in Iraq. Granted, some of these operations might have taken longer, created some international tension, or even been less "successful" in the short term, but the balance of the results might have been better for our long term security. Democracies tend to be more moderate and a bit less fickle in their foreign policy (e.g,. look at the elected organs of the Iranian government).
Looking to the future, now that the pressures of the cold war have abated, we do not have to court dictatorships as much as before. We have the luxury to take some less expedient foreign policy positions to invest in our long term intersts, which I think would be served better by a world with more democratic governments.
Specifically, we ought to be financially and militarily backing democratic resistance organizations in the autocracies that bother us the most, even when the democratic groups may not be as well organized as less democratic factions.
In cases where we directly militarily intervene on a large scale, we ought to bear in mind that, paradoxically imposing democracy by force actually works rather well as in Japan, Western Europe, Panama, and Haiti (I mean, the results we get are at least as good as we seem to get from imposing autocratic governments--e.g., our old Panama policy). We ought to be promoting democracy in our propaganda, and foreign aid programs. Along these lines, as John Gilmore pointed out at a PECSENC crypto advisory panel meeting a few years ago, we ought to be aggressively exporting cryptography. If the ordinary citizenry of foreign countries is using cryptography too strong for their governments to break, that is an extremely cost-effective way to promote more democratic and ultimately more moderate governments.
You're confused about multiople meanings of the term "relocated." Position independent code can be loaded at different addresses ("relocted"), without the need to change values of various bytes in the.text section to be (also sometimes referred to those bytes being "relocated"). Instead, shared libraries on x86-ELF to PC-relative jumps and calls to locations in the Procedure Linkage Table that are always at a precalculated distance from the caller, no matter where the library has been loaded. I believe that references to the same external routine use the same PLT entry, just like objprelink does (although you pay other performance costs for using -fPIC).
Although objprelink looks useful, I believe ELF
shared libraries already do this for the calls that they make (via the Procedure Linkage Table).
So, I think you could get a similar result by compiling your KDE applications as shared libraries. For example, konqueror's main() function would become konq_main(), and the konqueror program could be installed as a shared library, plus a trivial program for the actual konqueror executable:
The disadvantage of this approach would be that you would pay the other performance costs of
compiling everything with Position Independent Code (-fPIC), but the advantage would be that you would probably break up the non-library part of the program into other libraries that might be useful to other programs.
"Small programs; big libraries" seems to a common characteristic among the most popular Graphical User Interface systems. Maybe there would be an advantage to taking that to the extreme.
Since you worked on one of these drives, do you happen to know where one might find documentation on the SCSI commands used to control them? There is a proprietary version of cdrecord that is supposed to be able to control DVD-R drives, so this implies that there are some additional commands necessary beyond what is normally used to drive a CD-R drive. My hope is that this is documented somewhere on t10.org.
I am sickened by this morning's horrible acts of terrorism, and I morn for what will surely turn out to be thousands of dead.
We, in the technical community, need to make sure that this event is not turned into a political opportunity for other groups that seek to undermine our freedoms, also for what they see as the greater good. If we yield to them, then we will have also lost. I am talking about not one specific group, but many: those who seek to trade away our rights of privacy, our relatively free access to information, and due process.
For example, I don't know if it's true, but I remember hearing a rumor that then-FBI director Louis Freeh told a congressional committee in closed session that if cryptographic export restrictions were loosened that he would finger those who voted for it at the next terrorist incident. Louis Freeh has his own political problems right now, but you can bet that others of similar mind will articulate this view in the news and talk shows over the next week.
Fortunately, while there is probably little you can do to help the victims of this morning's attacks if you are not in the affected areas, there are things that you can do to help defend our freedoms from opportunist political attack.
If you have some relevant credentials and are well spoken, consider contacting reporters and just offering yourself as a resource for some quotations on why we should not ban cryptography, require hard ID's for internet access, etc. For example, taking the perspective that a good offense is the best defense, you might want to make the point that we need ubiquitous strong cryptography to impede cyber cracking, especially when you consider that stolen information is often of a nature that it cannot be made secret again once the information is out. These terrorists must have gotten access to some information that they should not have had at some point in the course of their preparations (we'll see what the details turn out to be). That might turn out to yield a few examples of the sort of thing that could have benefitted from ubiquitous encryption. (I imagine there will be speculation in the other direction that these terrorists used might have used strong crypto themselves.)
You might consider submitting letters to the editor of print media (some people still get their information that way, I hear). Finally, you might want to write your representatives and senators know. I imagine that congress is going to get so much mail over this that letters on this topic will not be read in detail by anyone, but some consideration is but I imagine that attention will be paid to how many letters say, in essence, "don't put the constitution in the paper shredder yet."
I can accept that some institutional changes may have to be made to reduce chances of something like this happening again, and I certainly don't mean to detract from the significance of the tremendous tragedy to that has occurred today.
Let's just make sure that this does not turn into a second tragedy with respect to the way our society works.
Slashdot Mirror
That report's logic is fallacious. Consider the case of case of two similar individuals: one who lives to a to a bit less than 65 in 1940, and another who lives a bit past 65 in 1990. People whose life expectencies have increased from below 65 to just above 65 will reduce "average life expectancy of people at age 65" just by their living past 65. Their negative life expectancy past 65 in 1940 was not counted, but there marginally positive life expectancy past 65 in 1990 is.
Just to clarify the parent poster's point, it is theoretically possible for everyone in a country to reduce all of their salaries and government benefits to compensate for their
decreasing productivity. However, it is generally impractical to get everyone to agree to do this in sync, while it is trivial if not automatic if that country has a separate currency.
The situation in Argentina is a bit different, because part of the problem is that the government claimed to back its currency with more US dollars than they actually currently have.
The question of porting a non-unix MacOS X application to Linux makes me wonder what the current state of MacOS emulation under Linux is. I see that Basilisk is apparently a GPL'ed 68k Mac emulator under relatively active development, and that the proprietary executor is still available, along with Carbonless Copies from the same company. Also, a couple of others are discussed on emulators.com.
The technique is called Forward Error Correction. I don't know much about it, but I know that you can do things like break up a file of N*B bytes into 2N blocks of B bytes each and then be able to reconstruct the file from any N of the 2N blocks. The GPL'ed Mojonation system uses it, if I recall correctly, to distribute each 32kB chunk of data into eight 8kB blocks allowing reonstruction from any four of them.
Oops, sorry. Here is the correct link for the IBM ITQX20.
I think there is still some additional programming productivity to be had from a bigger monitors, so I think it would be an appealing purchase for software devopers if you could get it down to ~$2k (hopefully due to volume).
By the way, for anyone whose sights are set higher than this, there was an article about how IBM also makes a similar 22" 3840x2400 TFT monitor that they were selling for $16k.
[...] even without faster than light travel (the idea is exponential growth -- we send two colonies, then they)
Just to be pedantic, let me point out that this is not exponential (2**n) growth, because it is limited by the speed of light. Instead, there would be no more than cubic growth (n*n*n), because the rate of growth would be limited to the size of a sphere expanding at the speed of light from where this intelligent species originated.
The numbers that you mention already accomodate this, but I thought this subtlety might be of interest to slashdot readers anyhow.
If these unnamed businesses that find even the LGPL onerous are legitimate, they should have no problem paying you serious money to switch to the new BSD terms. They support the proprietary model, and you've worked hard on this project.
If they do not pay, then, your sticking with LGPL will help the development of the core free version (although perhaps hindering proprietary forks) by ensuring that future enhancements to libFLAC are incorporated, which is particularly important in the case of something that is likely to be incrementally improved by tinkering or where standardization and interoperability may be affect adoption.
Although I personally prefer LGPL'ed libraries, I would be remiss in not mentioning that, by similar argument, you might could go further and set up a "FLAC consortium" that companies would pay a small amount of money to in order go get the right to use libFLAC under something like LGPL (but which would not conflict with the requirement to pay dues).
Comdex is not the first major computer trade show to ban cameras. At LinuxWorld in San Francisco in August(?), I watched a show staff member enforce it against some random attendee.
Personally, I think a ban on cameras at a trade show gives the impression of an industry trying to avoid accountability to its would-be buyers. I would much prefer exhibiting at trade shows that allow cameras.
I am posting this from a notebook computer that has all partitions encrypted except for a boot partition at the front of the disk. The kernel boots an initial ramdisk with an /sbin/init script that does essentially the following, using cryptoapi, the successor to the linux "kerneli" patches.
modprobe cryptoapi /dev/discs/disc0/part6 /dev/loop/0 /dev/loop/0 /newroot /newroot ./bin/chroot . ./sbin/init $@
modprobe cryptoloop
modprobe cipher-aes
losetup -e AES
Password:
mount -t ext2
cd
exec
This should work with any disk file system, not just ext2.
I have been using this arrangement for several months now on a couple of computers, the slowest of which is a Kapok 1100M that uses a 233MHz Pentium II process and, I believe, PC-66 SDRAM. On that computer, the change in interactive responsiveness is hard to notice, but it is noticible for disk intensive activities. I have not timed it, but I think that big rsync runs are at least a factor of two slower.
I do not run swapping on these computers, as I've seen claims that there are more potential deadlocks when attempting to swap to an encrypted partition than when attempting to swap to an unencrypted partition.
I hope this information is helpful.
A few notes on your idea:
1. There is no need to build a mechanical autoloader. IDE controllers and removable drive bays are cheap, less than $25 per drive, making them much cheaper than a robotic loader, with greater reliability and response time to boot. IDE drives can be spun down when they've been idle for a while, so electricity consumption should be similar.
2. I believe that Linux IDE does not currently support hot swapping of drives, although the PCMCIA drives do support removal of an entire IDE controller, which is what happens when you remove a CompactFlash card.
3. My understanding is that hard drives are not hermetically sealed but rather have air filters similar to what you stuff at the end of a cigarette is made of. I believe that when hard drives are not in use, they can accumulate dust internally and are more likely to have problems. You may also have problems with their greater sensitivity to being dropped and to statically electricity. So, you may want to store them in sealed conductive bags.
4. In my humble opinion, I think you have a good idea. I believe that, disk-based backups are much more valuable to an organization because they're easy enough to use that people will save time by doing minor recovery tasks. In comparison, with tape backups, the effort of doing a restore can be so much that people will often opt to spend an hour regenerating their previous work from scratch instead.
Sorry, I thought I checked all of my links. The sphinx2 sourceforge links should be http://sourceforge.net/projects/cmusphinx/.
At LinuxWorld in San Francisco, Geoff Harrison (sp?), co-author of the Enlightenment window manager, talked about text/speech conversion. If I recall his talk correctly, most proprietary voice recognition software is derived from the free sphinx system developed at Carnegie-Mellon University, which also has a sourceforge area. The web page at CMU talks about a sphinx3 program that is slower but more accurate, which sounds like a better fit for transcribing a previously recorded interview, but I did not see a link to the source code for it.
Geoff's employer, Cepstral, also claims to have released some related software under "relatively liberal" permissions. (Sorry, I could not find any download links or texts of the corresponding copying permissions.)
The sphinx2 copying permissions have an advertising restriction similar to the one that made the old BSD copying conditions GPL incompatible but "free" in the opinion of the Free Software Foundation. I do not know about the situtation with sphinx, sphinx3 or any Cepstral contributions.
I don't know what the law is in Canada about 802.11b wireless ethernet, but people do make line of sight point-to-point 802.11b links with dish antennas on both ends that are as long as 20+ miles. I understand that Linksys WAP11 access point (US$200) can be configured as a repeater, as can some Cisco Aeronet unit that costs US$1k. Of course, when you include the antennas, housing, professional design and installation, the cost of making these repeater stations will go way up, but still nowhere near US$80k.
If you're talking about spinlocks and you're running on a single CPU machine (even with an SMP kernel), the kernel never blocks on a spinlock, because there is never spinlock contention (except for a kernel locking bug, where the kernel will lock up hard at that point). The overhead of the checking the spinlocks is also very small (nanoseconds on that single CPU system, especially since there is no cache snooping). So, the delays that are long enough to deplete sound buffers are going to occur because the granularity of time slices between processes is too long, not because of lock contention.
With HZ=100, the timer tick is 1/100th of a second (ten milliseconds), and any process running at a CPU priority of nice 0 (the standard), nice -1, nice -2 or nice -3 will get five ticks (see the definition of TICK_SCALE in kernel/sched.c), so each time slice will be 50ms, which begins to approach the buffer size of sound cards when you have a few runnable processes, and is already much longer than video frame rates.
For things like playing buffered video and sound, where you just need to get the CPU every few milliseconds, I would think that the system call code paths are not so long that you really need a preemtable kernel. I would expect that it would be enough to just change the time quantum from 1/100th of a second to, say, 1/5000th, by replacing the "#define HZ 100" in include/asm/param.h to "#define HZ 5000". I have not tried this, but this sort of thing has been discussed on the linux-kernel mailing list. One person there reported that doing this prevented his Palm cradle to no longer be able to sync, so be warned that this seems to trip at least one bug.
As someone who has only looked through the preemtable system call patch and never tried it, my impression is that while it may be great, I expect its design to change a bit. Right now, under this patch, you build the kernel with basically a fixed number of fake CPU's that basically make your computer look like it has more CPU's than it does. The kernel being preempted basically causes the old kernel's state to become associated with one of these fake CPU's and then the preempting context takes over a real CPU. [I'm really not doing justice to code in this oversimplified and possibly misinformed description.]
In the future, I would hope that the need for a fixed number of fake CPU's would disappear and the "old fashioned" way of doing context switching would also disappear when the preemtable kernel option is selected. In other words, that would be the only way that context switching would normally occur, rather than having two ways of doing the same thing.
I have always regarded the potential for a preemtable kernel as the biggest side benefit of the move to SMP in Linux 2.0, and I'm glad to see people turning it into a reality. However, maintaining the option of making a non-preemtible kernel may be worthwhile, at least for a uniprocessor kernel, because the preemtible kernel code relies on running an multiprocessing kernel (even on a uniprocessor), which has a slight performance cost in setting and releasing all those locks that never once experience contention.
It looks like a great product, but I notice a few minor nits:
Vertical refresh rate: 41-56Hz. Since no multiple of 30Hz is available, playback of DVD's will not be as perfectly smooth as it could be. On the other hand, people generally do not run CRT's at a multiple of 30Hz, due to issues of phosphor image persistence and 60Hz AC power in many countries.
26.4 pounds, 7.7 inch depth, 111 Watt power consumption (so it probably has a fan). In terms of lightness, sleakness, power efficiency and quiet, this display is about a third of the way toward a CRT. So, it's not as appealing as a really expensive high tech toy.
Video card is PCI rather than AGP. With 24-bit pixels, the frame buffer is at least 26MB, and a 33MHz 32-bit PCI bus can only tranfer a maximum of 133MB/second, so the entire screen can only be redrawn from scratch at five frames per second. Maybe the PCI card is 66Mhz or 64-bit (probably not).
On the positive side, I wonder if the card that comes with the T220 can be obtained separately at a reasonable price and can drive the ITQX20's digital inputs (the 2048x1536 20.8" TFT display that is in the T210 monitor). Then you could build something for a few thousand dollars that would still be a big step up from the 1600x1024 flat panels.
it IS only a 22inch widescreen. That means it has less image height than a normal 20inch CRT.
If you read the chart at the bottom of the web page describing the T220, you will see that the T220 has a (diagonal) viewable image size of 22.2 inches, or the equivalent of approximately a 24-25 inch CRT, since CRT's are measured by the outside tube dimensions while flat panels are generally measured by actual viewable area.
On the other hand, if you only want viewable image size, you can get some pretty nice projectors or big monitors for a lot less than $16k.
I'd like to see someone create a web database on politicians' voting records on issues relevant within the technical community (ideally with some kind of interface for selecting which issues you care about, and even in which direction). Hopefully, this would help people make more informed decisions, and, just the public knowledge that such a database is being compiled and published might influence legislative decisions a bit.
0 .html
0 .html
g .html
0 .html
0 .html
Anyhow, here is a small start. I would encourage anyone with additional data to post it right here. I'll try to add it to this list, and perhaps someone more ambitious will be able to browse the follow-ups and start a real web database on this.
United States Senate:
CALIFORNIA: Diane Feinstein, Democrat, Bad
- Co-sponsored "Combating Terrorism Act of 2001"
http://www.wired.com/news/politics/0,1283,46852,0
o Elected in 1992 (short term), 1994, 2000, 2006
MICHIGAN: Carl(?) Levin, Democrat
+ Argued against "Combating Terrorism Act of 2001"
NEW HAMPSHIRE: Judd Greg, Republican, Bad
- Called for crypto key escrow after World Trade Center bombing
http://www.wired.com/news/politics/0,1283,46816,0
o http://www.senate.gov/~gregg/body_about_judd_greg
o Elected in 1998, 2004?
UTAH: Orrin Hatch, Republican, Mixed
+ Suggested mandatory licensing for online music copyrights
- Co-sponsored "Combating Terrorism Act of 2001"
http://www.wired.com/news/politics/0,1283,46852,0
o Elected in 1976, 1982, 1988, 1994, 2000?, 2006?
VERMONT: Patrick Leahy, Democrat, Good
+ Argued against "Combating Terrorism Act of 2001"
http://www.wired.com/news/politics/0,1283,46852,0
o 1974...1998, 2004?
United States House of Representatives:
Bob Goodlatte, Virginia, 6th District, Republican, Good
+ Co-sponsored lifting of encryption controls
+ Speaking out against encryption controls after World Trade
Center Bombing. http://news.cnet.com/news/0-1005-200-7249721.html
Zoe Lofgren, California, Democrat, 16th District, Good
+ Co-sponsored lifting of encryption controls
We don't need to play defense on this issue. We can play offense.
The increased terrorist attacks underscore the need to strengthen our computer networks with strong unbreakable cryptography. Some well meaning but misguided inviduals may argue that we should weaken our computer infrastructure with back doors to ease law enforcement, but that weakening would create a greater opportunity for terrorists, as it is a virtual certainty that, with so many back door keys, some will fall into the wrong hands.
In foreign policy, we neeed to promote the use of strong cryptography abroad, not only to strengthen the computing infrastructure of free countries, but because strong cryptography in the hands of the citizenry could help undermine oppressive regimes and enable more internal efforts at democratic reform. Since it is from oppressive regimes where terrorism seems to originate most often, making these governments more democratic is likely to be one of the most cost effective ways of reducing the terrorist threat.
We need to pueblicize the idea that the governments of the free world should be actively promoting strong cryptography, both to guard against potential cyber-attack and to reduce terrorism at its source.
Terrorism originates disproprotionately from areas with autocratic governments, such as many arab countries, Afganistan, Iran and Iraq (there are exceptions, like Northern Ireland). To reduce terrorism in the long run, rather than changing our government to look slightly more like the governments that breed terrorism, we should instead try more ardently to change autocratic governments to be more democratic.
Looking back, imagine if we had had the guts in the Soviet-Afghan war to insist on also funding the more democratic elements of the Afghan resistance, against the wishes of Pakistan. Imagine if we had installed a democracy in Kuwait. Imagine if we did more to support democratic forces in Iraq. Granted, some of these operations might have taken longer, created some international tension, or even been less "successful" in the short term, but the balance of the results might have been better for our long term security. Democracies tend to be more moderate and a bit less fickle in their foreign policy (e.g,. look at the elected organs of the Iranian government).
Looking to the future, now that the pressures of the cold war have abated, we do not have to court dictatorships as much as before. We have the luxury to take some less expedient foreign policy positions to invest in our long term intersts, which I think would be served better by a world with more democratic governments.
Specifically, we ought to be financially and militarily backing democratic resistance organizations in the autocracies that bother us the most, even when the democratic groups may not be as well organized as less democratic factions. In cases where we directly militarily intervene on a large scale, we ought to bear in mind that, paradoxically imposing democracy by force actually works rather well as in Japan, Western Europe, Panama, and Haiti (I mean, the results we get are at least as good as we seem to get from imposing autocratic governments--e.g., our old Panama policy). We ought to be promoting democracy in our propaganda, and foreign aid programs. Along these lines, as John Gilmore pointed out at a PECSENC crypto advisory panel meeting a few years ago, we ought to be aggressively exporting cryptography. If the ordinary citizenry of foreign countries is using cryptography too strong for their governments to break, that is an extremely cost-effective way to promote more democratic and ultimately more moderate governments.
You're confused about multiople meanings of the term "relocated." Position independent code can be loaded at different addresses ("relocted"), without the need to change values of various bytes in the .text section to be (also sometimes referred to those bytes being "relocated"). Instead, shared libraries on x86-ELF to PC-relative jumps and calls to locations in the Procedure Linkage Table that are always at a precalculated distance from the caller, no matter where the library has been loaded. I believe that references to the same external routine use the same PLT entry, just like objprelink does (although you pay other performance costs for using -fPIC).
Although objprelink looks useful, I believe ELF shared libraries already do this for the calls that they make (via the Procedure Linkage Table). So, I think you could get a similar result by compiling your KDE applications as shared libraries. For example, konqueror's main() function would become konq_main(), and the konqueror program could be installed as a shared library, plus a trivial program for the actual konqueror executable:
main(int argc, char **argv, char **envp) {return konq_main(argc, argv, envp);
}
The disadvantage of this approach would be that you would pay the other performance costs of compiling everything with Position Independent Code (-fPIC), but the advantage would be that you would probably break up the non-library part of the program into other libraries that might be useful to other programs.
"Small programs; big libraries" seems to a common characteristic among the most popular Graphical User Interface systems. Maybe there would be an advantage to taking that to the extreme.
Since you worked on one of these drives, do you happen to know where one might find documentation on the SCSI commands used to control them? There is a proprietary version of cdrecord that is supposed to be able to control DVD-R drives, so this implies that there are some additional commands necessary beyond what is normally used to drive a CD-R drive. My hope is that this is documented somewhere on t10.org.
I am sickened by this morning's horrible acts of terrorism, and I morn for what will surely turn out to be thousands of dead.
We, in the technical community, need to make sure that this event is not turned into a political opportunity for other groups that seek to undermine our freedoms, also for what they see as the greater good. If we yield to them, then we will have also lost. I am talking about not one specific group, but many: those who seek to trade away our rights of privacy, our relatively free access to information, and due process.
For example, I don't know if it's true, but I remember hearing a rumor that then-FBI director Louis Freeh told a congressional committee in closed session that if cryptographic export restrictions were loosened that he would finger those who voted for it at the next terrorist incident. Louis Freeh has his own political problems right now, but you can bet that others of similar mind will articulate this view in the news and talk shows over the next week.
Fortunately, while there is probably little you can do to help the victims of this morning's attacks if you are not in the affected areas, there are things that you can do to help defend our freedoms from opportunist political attack.
If you have some relevant credentials and are well spoken, consider contacting reporters and just offering yourself as a resource for some quotations on why we should not ban cryptography, require hard ID's for internet access, etc. For example, taking the perspective that a good offense is the best defense, you might want to make the point that we need ubiquitous strong cryptography to impede cyber cracking, especially when you consider that stolen information is often of a nature that it cannot be made secret again once the information is out. These terrorists must have gotten access to some information that they should not have had at some point in the course of their preparations (we'll see what the details turn out to be). That might turn out to yield a few examples of the sort of thing that could have benefitted from ubiquitous encryption. (I imagine there will be speculation in the other direction that these terrorists used might have used strong crypto themselves.)
You might consider submitting letters to the editor of print media (some people still get their information that way, I hear). Finally, you might want to write your representatives and senators know. I imagine that congress is going to get so much mail over this that letters on this topic will not be read in detail by anyone, but some consideration is but I imagine that attention will be paid to how many letters say, in essence, "don't put the constitution in the paper shredder yet."
I can accept that some institutional changes may have to be made to reduce chances of something like this happening again, and I certainly don't mean to detract from the significance of the tremendous tragedy to that has occurred today. Let's just make sure that this does not turn into a second tragedy with respect to the way our society works.