I had to implement something like this to dynamically throttle packets back based on the load in a router type box. It's not rocket science. I think Linux (if it doesn't already do this) could do it fairly easily with their NAPI networking interface, since the OS can slow down polling and assign a higher priority to audio and video.
Actually, he did not fire all of the US attorneys. He kept Michael Chertoff.
Also, it is quite customary for a new president to fire all attorneys and replace them on entering office. It is unprecedented to fire attorneys mid-term, however, and especially for political purposes since the attorneys are supposed to be apolitical.
Reagan had his own faults as well, such as bowing down to the terror campaign against US troops in Lebanon (On March 31, 1984 Reagan ordered the U.S. marines to return home after the bombing). Or how about Reagan giving arms to Iran?
Remember that he was also a co-author of the PATRIOT act and advised the CIA on the limits of coercive interrogation (aka torture). I don't think this man should be involved anyplace in government, like many Bush appointees.
The standard APIs for obtaining this information read/etc/passwd. Passwords are no longer stored there, however, but are in/etc/shadow which is not accessable by users other than root.
There is a side benefit to road maintenance with higher efficiency vehicles. The higher efficiency is often in part created by making the vehicle lighter, which saves wear and tear on the road. I see streets with signs stating a 6000 or 8000 lb weight limit and I know many vehicles exceed this. For example, a Hummer H2 weighs between 6400 and 8600 lbs and a Ford Excursion has a gross weight of 9200 lbs.
The smaller and more efficient cars weigh quite a bit less and thus result in a lot less wear and tear on the roads, for example, the smaller SUVs like the Escape weigh under 4000 lbs. Most passenger cars are well under 4000 lbs (though a 2007 Crown Victoria has a curb weight of 4157 lbs). This is still well under the larger SUVs.
It would be great if they enforced this. I imagine some cities could make a bundle just driving down a street and seeing all the SUVs parked on the side of the road that exceed the weight limit, or at least just sit and pull over all the oversized vehicles. Overweight SUVs cause a lot more damage to the roads than regular cars to the roads. I'd love to see them ticket those vehicles and put that money towards fixing and maintaining the roads in the area, many of which are in terrible shape, and some of which is easily attributed to overweight vehicles. I see intersections where there are ruts where the tires sit at some stoplights, for example.
At least the larger commercial vehicles are designed to better distribute the weight, having wider tires or just more wheels to help carry the load.
Userland ZFS isn't all that interesting as a Linux file system due to the big performance hit. I would like to see it as a kernel module, though I think it would require some major changes to the LVM layer, which I think was one of the complaints about Reiser4.
A userland file system is really only useful if performance is not a requirement. I.e. NTFS-3G is great for those times where access to a NTFS partion is required.
I'm not saying that ZFS is perfect, far from it. Some key features are not fully implemented yet.
I could see Novell using this to the advantage of Linux. For example, they could require that Sun allow ZFS and some of the other Solaris technologies be made available under the GPL as well. (I personally would love to see Linux gain a filesystem with some of the features built into ZFS like snapshots).
>> Are humans capable of producing more CO2 per decade than say, a single volcanic eruption?
Yes. Humans put out well over 100 times as much CO2 as all volcanic activity combined.
>> Does the amount of organisms capable of removing CO2 from the atmosphere increase as this new atmosphere provides an environment closer to the optimum for them?
It depends. There are limits to the number of organisms from other things like nutrients, hence projects to do things like dump extra iron in the ocean. Other carbon sequestration organisms like the Amazon rain forest are being lost as well. Some pollutants, like ground level ozone, actually reduce the amount of CO2 plants can take up.
>> Does the increase of CO2 (which is far denser than oxygen or nitrogen) at relatively LOW altitudes (because of this density) have ANY effect on the upper atmosphere? In fact, is heat really retained at ALL by a thin surface layer of CO2?
Yes. CO2 tends to get mixed fairly well into the upper atmosphere up to around 90km. See http://www.agu.org/pubs/crossref/1992/92JD01622.sh tml Note that the edge of space is considered to start at only 60km.
>> The "facts" are not as clear cut as you would like them to be. Of course it's easy if you only listen to what you WANT to hear.
Actually, they are fairly clear cut, and all of the arguments you have made have been discussed and covered ad nauseum. There is a lot of discussion of this and other arguments at http://www.realclimate.org/
The problem with hydrogen today is that most of it is made from fossil fuels, primarily natural gas, so the process of making pure hydrogen releases CO2. Also, I would think moving to a fuel cell would be much more efficient than an internal combustion engine, though at this time more expensive.
Sadly right now I have not seen any affordable technologies that can eliminate our dependence on fossil fuels for cars (though electric cars are coming down). We can't grow enough ethanol to fill our tanks (over 20% of all corn in the US goes to making ethanol, and the national average of ethanol use in fuel is about 3%).
Hydrogen is really an energy carrier rather than a fuel. It still is not that practical as a fuel since it requires refrigerating it to a very low temperature or compressing it to a very high pressure (both of which require a fair amount of energy to do). And hydrogen loves to leak. It will seep through the smallest holes and has a habit of making metal brittle.
I worked on the code for a portable tablet PC keyboard back in the early 1990s when I worked at GRiD Systems, who made tablet PCs and laptops, well before this patent.
Touch screen keyboards have been around forever. The one I worked on ran as a TSR under MSDOS and when triggered would take up part of the screen and would simulate a real keyboard. This was back around 1992-1993, well before this patent was filed. I know of other keyboards as well, such as one I saw on Geoworks on a Casio Zoomer and I'm sure others were also available.
My notes on the claims for the patent (quoted from the patent):
1. A method of entering data on a touch screen display, the method comprising: invoking a computer program in which user input is sought; invoking an input area, including a plurality of data input fields; invoking a graphical keyboard area incapable of user termination independent of termination of the input area, the graphical keyboard area having a plurality of keys on the display; selecting keys on the keyboard to provide the desired input; and automatically terminating the graphical keyboard area after the desired input is received in the input area.
The keyboard I worked on was capable of being toggled on or off by the user and was not application specific, but this is something rather minor and obvious.
2. The method of entering data on a touch screen display of claim 1 wherein the input area is created by an executable code.
Done. The keyboard I worked on would draw the keyboard in the lower half of the screen and shrink the text above it to fit (since it ran in text mode).
3. The method of entering data on a touch screen display of claim 2 wherein the executable code is compiled visual basic code.
Can't say it was in Visual Basic... the keyboard TSR I worked on was written in Turbo C with some assembly. The computer language used should not affect the patent.
4. The method of entering data on a touch screen display of claim 1 wherein the computer program invokes the input area.
This was not computer program invoked, but this is fairly obvious. I think there were other applications at that time where the application could invoke a keyboard for input fields. I don't recall if it was at a fixed location or not, though it might have been. I think GRiD's pen SDK had this capability. Usually it supported handwriting recognition that was input field specific (i.e. if an input field expected only numbers it would only recognize numbers, or if letters only, it would only accept letters. This was to improve the accuracy of the handwriting recognition.)
5. The method of entering data on a touch screen display of claim 4 wherein the computer program accesses a dynamic link library file in order to invoke the input area.
A TSR under MSDOS is sort of a dynamic link library, since it hooks itself into the OS and BIOS and is called by the application. Dynamic link libraries are pretty obvious for functionality such as this.
6. The method of entering data on a touch screen display of claim 5 wherein the dynamic link library file is a C++ program.
The keyboard I worked on was not language specific and it shouldn't matter what language it's written in. The keyboard was written in C and assembly, but would work with applications written in any language (including C++).
7. The method of entering data on a touch screen display of claim 1 wherein the computer program is executing on a personal computer.
The pen computer was basically a personal computer and the keyboard program would also run on a regular PC with a mouse or similar input device. The computers ranged from 8088 to 80486 machines at the time.
8. The method of entering data on a touch screen display of claim 1 wherein the computer program is executing on a pen-based computer.
That's what the keyboard I worked on usually ran on.
A number of cameras have support for dealing with hot pixels and dust on the sensor. Also, as you say, some conversion algorithms are better than others. dcraw, for example, results in a bit sharper conversion than the in-camera or vendor's raw processing software for my camera and the workflow software I use is based on this for it's raw conversion.
Some cameras also have weird pixel layouts. Fuji's SuperCCD, for example, uses hexagonal pixels, and each pixel is actually two, a large and a small one to increase dynamic range. Then there's Kodak who is showing off support for a RGBW filter, where instead of RGBG they replace one of the green pixels with a white pixel.
Taking a quick glance at Microsoft's HDPhoto standard it looks like it is not really suitable for capturing raw image data for cameras.
In a digital camera, a pixel is red, green, blue and sometimes additional colors laid out in a pattern that can differ from camera to camera. A pixel is not RGB (unless it's a Fovon sensor), so standard lossless formats like PNG or TIFF won't work. HDPhoto supports N color channels and more than 8 bits per color, but I do not see support for the raw CCD data, which is usually not RGB, but R, G, or B (sometimes with additional colors).
I like to preserve my pictures in RAW format since as time goes by, the algorithms to convert the image to a RGB image suitable for displaying keep improving. Also, when editing my photos, some of the processing is done on the raw data before converting it to RGB. Raw data helps for things like noise filtering, for example, since the noise filtering software can be aware of the camera's CCD properties (Noise Ninja, for example, has profiles for my camera at different ISO settings).
The only problem with current raw photos is that each manufacturer seems to have their own format which is incompatible with other manufacturers, or even incompatible between different cameras. It would be nice if they could standardize on something like OpenRAW.
Now, as much as I dislike Microsoft, I think this could be good for regular photos since the compression is about as good as Jpeg2000 (assuming Microsoft isn't spreading FUD) but with a much faster encoding/decoding speed. This could also be a good format for most people taking pictures (who are happy with JPEG).
I have had very good luck using Spamhaus and cbl.abuseat.org. I use it to outright block spam and have never had a problem with legitimate email. I go one step further, however, and block several countries. I don't know anybody in those countries, like China, Russia and Nigeria, so I just block them entirely. That has also made a huge difference.
Exactly. I can't count how many scripts fail on Solaris 9 because of Sun's/bin/sh missing some key functionality (usually replacing it with/bin/bash fixes it). And why should scripts have to hunt around all over the place just to find a working version of very common tools (like Sun's sed which used to be quite broken). And some very useful features are always missing (recursive grep anyone).
Trying to compile GNU software on Solaris 9 is often a painful experience because even their libc and header files are in the dark ages (i.e. many ISO C99 features are missing). I haven't tried Solaris 10 and moved on to Linux at work.
I remember reading a discussion by the Opensolaris folks claiming how much better their tools were than the Gnu tools. They were singling out Solaris TAR and saying what a mess the Gnu version is. As a user, Solaris TAR is crap to use compared to GnuTAR. It can't even handle tar files over 2GB, for example, and I've had several tar files it can't handle that GnuTAR can. I also like the built-in support for bzip2 and gzip in GnuTAR. Now granted, I haven't tried Solaris 10, but I suspect the problems remain. That isn't to say that GnuTAR is perfect... I was running an older version that would truncate some filenames.
Another one that caused me endless frustration was Solaris newgrp did not allow you to specify a command line like the Linux one did. I ended up porting over the Gnu version just so I could do my job without having to manually type in a command as part of a build procedure.
At my job I've been maintaining KDE for Solaris for a bunch of Sun users. When I migrated my desktop to Linux I'm still having to support KDE for them (and that's not my job, I'm not in IT). None of the developers like Sun's Gnome 2.0 that's included with Solaris 9, and newer versions have problems compiling because Sun still does not support the X render extension (on Sparc). Trying to compile KDE was difficult, since Sun's libraries and tools are often broken or so out of date. I also have had to compile GCC for Solaris to do it, since Sun's C++ compiler we have barfs on a lot of open source packages. I've also hit a number of problems because numerous features are missing in Sun's libc, even though they've been part of the posix or ISO standard for many years (i.e. missing stdint.h), including some parts of stdio.h. (stdint.h is part of the ISO C99 standard, well before Solaris 9 came out).
I remember having tons of problems with Sun's sed because it would silently truncate after 4-8KB of input.
The only thing I see is garbled text with xemacs, a garbled cursor when moving between screens with Xinerama, Google Earth failing to start without adding a hack, and general slowness with my screen saver running maybe one frame per second.
Oh, I also see response emails from ATI that they don't support the Linux driver when I submit bugs using their bug submission package (which has all the support for selecting Linux).
A friend of mine has an iPhone and an email from the Debian security mailing list caused the mail app to crash. I also recall reading that most apps on the iPhone run as root. Might just be a nice buffer or stack overflow to be exploited.
He may have, but he was more afraid of Iran than the US. If Iran wasn't sure if there were WMDs or not that would be an incentive for them not to attack Iraq. Iraq was weak and Saddam knew it.
Did the president pick the joint chiefs and the top-level CIA people? (serious question, I don't know off the top of my head).
He did pick the head of the CIA George Tenant. Also, Cheney and Rumsfield created their own group inside the Pentagon to go through all the evidence that was separate from the CIA. The people in that group were not experienced analysts and were not able to effectively separate the wheat from the chaff, plus they had an explicit agenda as to what they wanted the outcom to be, which may or may not have been the truth. Time has shown that it was not the truth. The CIA didn't have the best intelligence, but they were not totally off. Bush had an agenda from day one from the Project for a New American Century which many top people in the Whitehouse belonged. Also, Bush made the comment about Saddam by calling him "the guy who tried to kill my dad" which should also be telling.
I also find this useful. That way I can choose a different password for each site that requires them and can generate some pretty random passwords like D7fgy#h0xl for example. At least with kwallet, the passwords are all encrypted.
Out of curiosity I ran the password stealing test (as well as all of the other Javascript tests) with Konqueror and they all passed with no information leaked.
One nice thing is Kwallet is outside of the browser with access control to various applications. This means that when Konqueror wants to get a password, it sends a request to the kwallet app, which then can display a password dialog for the master password before responding to Konqueror.
I clicked on the update tool and it shows an update to Java 1.5. The description says:
Update Version: 3832-0 Category: Security
Status: Needed
The Sun JAVA JDK 1.5.0 was upgraded to release 12 to fix various bugs, including the following security bugs:
CVE-2007-2788 / CVE-2007-3004: Integer overflow in the embedded ICC profile image parser in Sun Java Development Kit (JDK), allows remote attackers to execute arbitrary code or cause a denial of service (JVM crash) via a crafted JPEG or BMP file.
CVE-2007-2789 / CVE-2007-3005: The BMP image parser in Sun Java Development Kit (JDK), on Unix/Linux systems, allows remote attackers to trigger the opening of arbitrary local files via a crafted BMP file, which causes a denial of service (system hang) in certain cases such as/dev/tty, and has other unspecified impact.
CVE-2007-0243: Buffer overflow in Sun JDK and Java Runtime Environment (JRE) allows applets to gain privileges via a GIF image with a block with a 0 width field, which triggers memory corruption.
Slashdot Mirror
I had to implement something like this to dynamically throttle packets back based on the load in a router type box. It's not rocket science. I think Linux (if it doesn't already do this) could do it fairly easily with their NAPI networking interface, since the OS can slow down polling and assign a higher priority to audio and video.
Actually, he did not fire all of the US attorneys. He kept Michael Chertoff.
/ tl03b.html
Also, it is quite customary for a new president to fire all attorneys and replace them on entering office. It is unprecedented to fire attorneys mid-term, however, and especially for political purposes since the attorneys are supposed to be apolitical.
Reagan had his own faults as well, such as bowing down to the terror campaign against US troops in Lebanon (On March 31, 1984 Reagan ordered the U.S. marines to return home after the bombing). Or how about Reagan giving arms to Iran?
http://www.pbs.org/frontlineworld/stories/Lebanon
That's not to say he wasn't a good president, but people tend to make him out to be a saint, which he was not.
Of course you are also probably upset that Clinton bombed an Al-Qaeda terrorist camp in Afghanistan where Bin Laden was believed to be.
All presidents make mistakes, just some seem to never learn from them.
Remember that he was also a co-author of the PATRIOT act and advised the CIA on the limits of coercive interrogation (aka torture). I don't think this man should be involved anyplace in government, like many Bush appointees.
The standard APIs for obtaining this information read /etc/passwd. Passwords are no longer stored there, however, but are in /etc/shadow which is not accessable by users other than root.
There is a side benefit to road maintenance with higher efficiency vehicles. The higher efficiency is often in part created by making the vehicle lighter, which saves wear and tear on the road. I see streets with signs stating a 6000 or 8000 lb weight limit and I know many vehicles exceed this. For example, a Hummer H2 weighs between 6400 and 8600 lbs and a Ford Excursion has a gross weight of 9200 lbs.
The smaller and more efficient cars weigh quite a bit less and thus result in a lot less wear and tear on the roads, for example, the smaller SUVs like the Escape weigh under 4000 lbs. Most passenger cars are well under 4000 lbs (though a 2007 Crown Victoria has a curb weight of 4157 lbs). This is still well under the larger SUVs.
It would be great if they enforced this. I imagine some cities could make a bundle just driving down a street and seeing all the SUVs parked on the side of the road that exceed the weight limit, or at least just sit and pull over all the oversized vehicles. Overweight SUVs cause a lot more damage to the roads than regular cars to the roads. I'd love to see them ticket those vehicles and put that money towards fixing and maintaining the roads in the area, many of which are in terrible shape, and some of which is easily attributed to overweight vehicles. I see intersections where there are ruts where the tires sit at some stoplights, for example.
At least the larger commercial vehicles are designed to better distribute the weight, having wider tires or just more wheels to help carry the load.
Userland ZFS isn't all that interesting as a Linux file system due to the big performance hit. I would like to see it as a kernel module, though I think it would require some major changes to the LVM layer, which I think was one of the complaints about Reiser4.
A userland file system is really only useful if performance is not a requirement. I.e. NTFS-3G is great for those times where access to a NTFS partion is required.
I'm not saying that ZFS is perfect, far from it. Some key features are not fully implemented yet.
-Aaron
I could see Novell using this to the advantage of Linux. For example, they could require that Sun allow ZFS and some of the other Solaris technologies be made available under the GPL as well. (I personally would love to see Linux gain a filesystem with some of the features built into ZFS like snapshots).
-Aaron
>> Are humans capable of producing more CO2 per decade than say, a single volcanic eruption?
h tml Note that the edge of space is considered to start at only 60km.
Yes. Humans put out well over 100 times as much CO2 as all volcanic activity combined.
>> Does the amount of organisms capable of removing CO2 from the atmosphere increase as this new atmosphere provides an environment closer to the optimum for them?
It depends. There are limits to the number of organisms from other things like nutrients, hence projects to do things like dump extra iron in the ocean. Other carbon sequestration organisms like the Amazon rain forest are being lost as well. Some pollutants, like ground level ozone, actually reduce the amount of CO2 plants can take up.
>> Does the increase of CO2 (which is far denser than oxygen or nitrogen) at relatively LOW altitudes (because of this density) have ANY effect on the upper atmosphere? In fact, is heat really retained at ALL by a thin surface layer of CO2?
Yes. CO2 tends to get mixed fairly well into the upper atmosphere up to around 90km. See http://www.agu.org/pubs/crossref/1992/92JD01622.s
>> The "facts" are not as clear cut as you would like them to be. Of course it's easy if you only listen to what you WANT to hear.
Actually, they are fairly clear cut, and all of the arguments you have made have been discussed and covered ad nauseum. There is a lot of discussion of this and other arguments at http://www.realclimate.org/
The problem with hydrogen today is that most of it is made from fossil fuels, primarily natural gas, so the process of making pure hydrogen releases CO2. Also, I would think moving to a fuel cell would be much more efficient than an internal combustion engine, though at this time more expensive.
Sadly right now I have not seen any affordable technologies that can eliminate our dependence on fossil fuels for cars (though electric cars are coming down). We can't grow enough ethanol to fill our tanks (over 20% of all corn in the US goes to making ethanol, and the national average of ethanol use in fuel is about 3%).
Hydrogen is really an energy carrier rather than a fuel. It still is not that practical as a fuel since it requires refrigerating it to a very low temperature or compressing it to a very high pressure (both of which require a fair amount of energy to do). And hydrogen loves to leak. It will seep through the smallest holes and has a habit of making metal brittle.
-Aaron
Touch screen keyboards have been around forever. The one I worked on ran as a TSR under MSDOS and when triggered would take up part of the screen and would simulate a real keyboard. This was back around 1992-1993, well before this patent was filed. I know of other keyboards as well, such as one I saw on Geoworks on a Casio Zoomer and I'm sure others were also available.
My notes on the claims for the patent (quoted from the patent):
1. A method of entering data on a touch screen display, the method comprising: invoking a computer program in which user input is sought; invoking an input area, including a plurality of data input fields; invoking a graphical keyboard area incapable of user termination independent of termination of the input area, the graphical keyboard area having a plurality of keys on the display; selecting keys on the keyboard to provide the desired input; and automatically terminating the graphical keyboard area after the desired input is received in the input area.
The keyboard I worked on was capable of being toggled on or off by the user and was not application specific, but this is something rather minor and obvious.
2. The method of entering data on a touch screen display of claim 1 wherein the input area is created by an executable code.
Done. The keyboard I worked on would draw the keyboard in the lower half of the screen and shrink the text above it to fit (since it ran in text mode).
3. The method of entering data on a touch screen display of claim 2 wherein the executable code is compiled visual basic code.
Can't say it was in Visual Basic... the keyboard TSR I worked on was written in Turbo C with some assembly. The computer language used should not affect the patent.
4. The method of entering data on a touch screen display of claim 1 wherein the computer program invokes the input area.
This was not computer program invoked, but this is fairly obvious. I think there were other applications at that time where the application could invoke a keyboard for input fields. I don't recall if it was at a fixed location or not, though it might have been. I think GRiD's pen SDK had this capability. Usually it supported handwriting recognition that was input field specific (i.e. if an input field expected only numbers it would only recognize numbers, or if letters only, it would only accept letters. This was to improve the accuracy of the handwriting recognition.)
5. The method of entering data on a touch screen display of claim 4 wherein the computer program accesses a dynamic link library file in order to invoke the input area.
A TSR under MSDOS is sort of a dynamic link library, since it hooks itself into the OS and BIOS and is called by the application. Dynamic link libraries are pretty obvious for functionality such as this.
6. The method of entering data on a touch screen display of claim 5 wherein the dynamic link library file is a C++ program.
The keyboard I worked on was not language specific and it shouldn't matter what language it's written in. The keyboard was written in C and assembly, but would work with applications written in any language (including C++).
7. The method of entering data on a touch screen display of claim 1 wherein the computer program is executing on a personal computer.
The pen computer was basically a personal computer and the keyboard program would also run on a regular PC with a mouse or similar input device. The computers ranged from 8088 to 80486 machines at the time.
8. The method of entering data on a touch screen display of claim 1 wherein the computer program is executing on a pen-based computer.
That's what the keyboard I worked on usually ran on.
9. The method of entering
A number of cameras have support for dealing with hot pixels and dust on the sensor. Also, as you say, some conversion algorithms are better than others. dcraw, for example, results in a bit sharper conversion than the in-camera or vendor's raw processing software for my camera and the workflow software I use is based on this for it's raw conversion.
Some cameras also have weird pixel layouts. Fuji's SuperCCD, for example, uses hexagonal pixels, and each pixel is actually two, a large and a small one to increase dynamic range. Then there's Kodak who is showing off support for a RGBW filter, where instead of RGBG they replace one of the green pixels with a white pixel.
-Aaron
Correct. Plus chromatic aberration and other things can also be better processed before the RGB conversion as well.
Taking a quick glance at Microsoft's HDPhoto standard it looks like it is not really suitable for capturing raw image data for cameras.
In a digital camera, a pixel is red, green, blue and sometimes additional colors laid out in a pattern that can differ from camera to camera. A pixel is not RGB (unless it's a Fovon sensor), so standard lossless formats like PNG or TIFF won't work. HDPhoto supports N color channels and more than 8 bits per color, but I do not see support for the raw CCD data, which is usually not RGB, but R, G, or B (sometimes with additional colors).
I like to preserve my pictures in RAW format since as time goes by, the algorithms to convert the image to a RGB image suitable for displaying keep improving. Also, when editing my photos, some of the processing is done on the raw data before converting it to RGB. Raw data helps for things like noise filtering, for example, since the noise filtering software can be aware of the camera's CCD properties (Noise Ninja, for example, has profiles for my camera at different ISO settings).
The only problem with current raw photos is that each manufacturer seems to have their own format which is incompatible with other manufacturers, or even incompatible between different cameras. It would be nice if they could standardize on something like OpenRAW.
Now, as much as I dislike Microsoft, I think this could be good for regular photos since the compression is about as good as Jpeg2000 (assuming Microsoft isn't spreading FUD) but with a much faster encoding/decoding speed. This could also be a good format for most people taking pictures (who are happy with JPEG).
-Aaron
I have had very good luck using Spamhaus and cbl.abuseat.org. I use it to outright block spam and have never had a problem with legitimate email. I go one step further, however, and block several countries. I don't know anybody in those countries, like China, Russia and Nigeria, so I just block them entirely. That has also made a huge difference.
-Aaron
Exactly. I can't count how many scripts fail on Solaris 9 because of Sun's /bin/sh missing some key functionality (usually replacing it with /bin/bash fixes it). And why should scripts have to hunt around all over the place just to find a working version of very common tools (like Sun's sed which used to be quite broken). And some very useful features are always missing (recursive grep anyone).
Trying to compile GNU software on Solaris 9 is often a painful experience because even their libc and header files are in the dark ages (i.e. many ISO C99 features are missing). I haven't tried Solaris 10 and moved on to Linux at work.
I remember reading a discussion by the Opensolaris folks claiming how much better their tools were than the Gnu tools. They were singling out Solaris TAR and saying what a mess the Gnu version is. As a user, Solaris TAR is crap to use compared to GnuTAR. It can't even handle tar files over 2GB, for example, and I've had several tar files it can't handle that GnuTAR can. I also like the built-in support for bzip2 and gzip in GnuTAR. Now granted, I haven't tried Solaris 10, but I suspect the problems remain. That isn't to say that GnuTAR is perfect... I was running an older version that would truncate some filenames.
Another one that caused me endless frustration was Solaris newgrp did not allow you to specify a command line like the Linux one did. I ended up porting over the Gnu version just so I could do my job without having to manually type in a command as part of a build procedure.
At my job I've been maintaining KDE for Solaris for a bunch of Sun users. When I migrated my desktop to Linux I'm still having to support KDE for them (and that's not my job, I'm not in IT). None of the developers like Sun's Gnome 2.0 that's included with Solaris 9, and newer versions have problems compiling because Sun still does not support the X render extension (on Sparc). Trying to compile KDE was difficult, since Sun's libraries and tools are often broken or so out of date. I also have had to compile GCC for Solaris to do it, since Sun's C++ compiler we have barfs on a lot of open source packages. I've also hit a number of problems because numerous features are missing in Sun's libc, even though they've been part of the posix or ISO standard for many years (i.e. missing stdint.h), including some parts of stdio.h. (stdint.h is part of the ISO C99 standard, well before Solaris 9 came out).
I remember having tons of problems with Sun's sed because it would silently truncate after 4-8KB of input.
-Aaron
The only thing I see is garbled text with xemacs, a garbled cursor when moving between screens with Xinerama, Google Earth failing to start without adding a hack, and general slowness with my screen saver running maybe one frame per second.
Oh, I also see response emails from ATI that they don't support the Linux driver when I submit bugs using their bug submission package (which has all the support for selecting Linux).
I curse the ATI graphics card where I work daily.
It wouldn't surprise me.
A friend of mine has an iPhone and an email from the Debian security mailing list caused the mail app to crash. I also recall reading that most apps on the iPhone run as root. Might just be a nice buffer or stack overflow to be exploited.
He may have, but he was more afraid of Iran than the US. If Iran wasn't sure if there were WMDs or not that would be an incentive for them not to attack Iraq. Iraq was weak and Saddam knew it.
He did pick the head of the CIA George Tenant. Also, Cheney and Rumsfield created their own group inside the Pentagon to go through all the evidence that was separate from the CIA. The people in that group were not experienced analysts and were not able to effectively separate the wheat from the chaff, plus they had an explicit agenda as to what they wanted the outcom to be, which may or may not have been the truth. Time has shown that it was not the truth. The CIA didn't have the best intelligence, but they were not totally off. Bush had an agenda from day one from the Project for a New American Century which many top people in the Whitehouse belonged. Also, Bush made the comment about Saddam by calling him "the guy who tried to kill my dad" which should also be telling.
I also find this useful. That way I can choose a different password for each site that requires them and can generate some pretty random passwords like D7fgy#h0xl for example. At least with kwallet, the passwords are all encrypted.
Out of curiosity I ran the password stealing test (as well as all of the other Javascript tests) with Konqueror and they all passed with no information leaked.
One nice thing is Kwallet is outside of the browser with access control to various applications. This means that when Konqueror wants to get a password, it sends a request to the kwallet app, which then can display a password dialog for the master password before responding to Konqueror.
I clicked on the update tool and it shows an update to Java 1.5. The description says:
/dev/tty,
Update Version: 3832-0
Category: Security
Status: Needed
The Sun JAVA JDK 1.5.0 was upgraded to release 12 to fix
various bugs, including the following security bugs:
CVE-2007-2788 / CVE-2007-3004: Integer overflow in the
embedded ICC profile image parser in Sun Java Development
Kit (JDK), allows remote attackers to execute arbitrary
code or cause a denial of service (JVM crash) via a crafted
JPEG or BMP file.
CVE-2007-2789 / CVE-2007-3005: The BMP image parser in Sun
Java Development Kit (JDK), on Unix/Linux systems, allows
remote attackers to trigger the opening of arbitrary local
files via a crafted BMP file, which causes a denial of
service (system hang) in certain cases such as
and has other unspecified impact.
CVE-2007-0243: Buffer overflow in Sun JDK and Java Runtime
Environment (JRE) allows applets to gain privileges via a
GIF image with a block with a 0 width field, which triggers
memory corruption.
I was obviously referring to the SQLite, not PostgreSQL.
I believe you no longer need to take the database offline and it now has an autovacuum daemon which automatically performs the operation when needed.