There's no way to "verify user accounts" until they post their first content - if there was, we could automate that verification.
I have run a fan forum (phpbb) for a musician for about 7 years. At peak times we have gotten up to 50-100 spam account attempts a day. I added a captcha which does not stop everything but slows it down a lot. http://www.stopforumspam.com/ is a good resource for checking if the email or nick is a known spammer. A quick google on the nick and you can often guess based on how many hits you get and the "interests" is a good indicator. Email addresses which look like incremented numbers, pharma ads, etc. are spotted and dropped.
We have seen multiple cases of countries which are sources of "cheap manual labor" as sources of semi-automated or repeated manual attempts with clearly algorithmically generated names. Given the subject matter of this forum, I felt OK blocking countries which cause too many problems. This would NOT be an acceptable solution for other forums.
I don't know if someone could automate it or not but I can tell you that we are fairly reliable at not allowing spam accounts.
I have jury duty this week in Huntsville Alabama and I will be paid $10 a day plus $.05 per mile for travel to and from the court house. If I am dismissed on the first day, I get nothing.
So at least here, you would make more begging or on unemployment than jury duty.
Jake.. 2009 was one of the most active years yet. The Google Summer of Code students were absolutely wonderful. I have pushed on test coverage to get as close as possible to 100%. Santosh was the GSoC student who worked with me and we got test reports near 100% on 5 target architectures (x86, sparc, powerpc, arm, and m68k/coldfire).
RTEMS targets a different POSIX profile than GNU/Linux. RTEMS provides a single process, multi-threaded environment with either constant or predictable execution times for nearly every service. A small RTEMS system would be 64Kb total code and data space but that would not be the smallest possible. A large RTEMS system with BSP TCP/IP, filesystem, webserver, and telnetd will fit into less than 512Kb code space. This is tiny, if not impossible, for a GNU/Linux system.
The summary specifically says Linux and the article linked to doesn't expand that statement. What about running it on *BSD, Haiku, Minix, RTEMS, etc.? Reading a quote in the article carefully says "redistributors". What is a redistributor? A Novell reseller?
As a result of today's expansion of that deal, Moonlight users will enjoy protection under the patent covenant regardless of whether they're using Novell's (NASDAQ: NOVL) Linux distro or another distributor's.
"A really important change in how the community and individuals will see and use Moonlight is a change and extension to the patent covenant that Microsoft provides to Novell and its end users," Brian Goldfarb, director of Web and user experience platforms at Microsoft, told InternetNews.com. "We're now increasing the reach of the agreement -- Microsoft's commitment not to sue Novell or Novell customers now extends to redistributors."
The first sentence is the author's so reflects their interpretation. The second is a Microsoft person who uses the phrase "not to sue Novell or Novell customers now extends to redistributors". So who does that actually cover?
I'm glad someone mentioned geocaching.:) I have been through a Magellan Meridian and now have a Garmin 60csx. I thought when I got the G1 it would replace my use of the Garmin and Palm (for notes and record keeping) for geocaching. It is very handy but has a number of lackings:
battery life on G1 pales in comparison to Garmin and Palm
GPS in G1 is slow to update
GPS in G1 can be accurate but is often 100m off when I find the cache.
GPS in G1 loses signal easily, Garmin is fast to lock on and stays that way.
My limited experience caching with people with an iPhone shows about the same behaviour.
So yes, some casual GPS users will go away if they have a smartphone with good mapping application but I think there is a LONG way to go before a smartphone GPS will be as good at the task as a dedicated GPS. Some shrinkage will undoubtedly occur as the "coolness" of the standalone GPS wears off and more cars get nav systems built-in. But I hope it doesn't kill the GPS manufacturers since their really is a difference.:)
I went geocaching this weekend for the first time with my G1 using GeoBeagle. I also have a Garmin 60csx which is a very nice handheld GPS. The G1's application was slower to update the distance to cache than the Garmin and would jump more than I was used to. The G1 would also lose the satellites when the Garmin wouldn't. But the G1 was very accurate, often showing 2 meters to the cache when we had found it.
Well as the maintainer of RTEMS (http://www.rtems.org)>, I am biased but there are a number of technical reasons. Deterministic (e.g. predictable or O(constant)) performance independent of the number of OS object instances in the system is a big reason. Support for priority ceiling and priority inheritance. Very low resource requirements with a minimal configuration on some CPUs starting at 16K. All software running on the target hardware appropriately licensed for use in embedded systems -- no pure GPL code. RPMs or Windows tool binaries for over a dozen CPU architectures. A project that is used to supporting software long term. RTEMS aims to be compliant with POSIX Profiles.51 and.52 as well as providing an API based upon the same standard as pSOS+ with a feature set tuned to make it easy to transition VxWorks applications. We even do automated code coverage analysis to ensure that our test suites execute as much of the OS as possible. We are currently over 97% of the binary and have a Summer of Code project working to improve that.
And RTEMS is has been on many spacecraft also from NASA, ESA and others around the world. Herschel, Planck, Electra, Venus Express, Dawn, Fermi, and THEMIS come to mind quickly. And that ignores many national laboratories around the world including Argonne,Stanford Linear Accelerator, Oak Ridge, Canadian Light Source, and Brookhaven.
RTEMS is a unique free software project that balances the needs of embedded projects that need stability and longevity with the release early and often approach of the FOSS community. We support student and hobby projects in parallel with some of the most serious projects out there. We are an open project that is 20 years old with 15 of those years captures in the CVS repository.
That's why RTEMS is a valid and very competitive FOSS alternative to VxWorks for a deeply embedded real-time operating system.
It spent years on the front of a 1987 Mazda 626 I bought new. I don't remember when I got it but it had to be before 1989. When I noticed the plate was getting rusty, I took it off and hung it in my office.
As maintainer of RTEMS, I am very proud that both spacecraft are running our free real-time operating system on at least the Spacecraft Management Unit (SMU). These are both important missions which promise to provide us with new insights.
This is the second year for RTEMS (http://www.rtems.org) to participate. RTEMS is a real-time operating system for embedded systems. This year we have some very exciting and achievable projects.
RunTime Tracing - Complete being able to selectively trace the execution flow on an embedded target, get the data off target and analyze it.
MMU Support in RTEMS - RTEMS has a single process, multi-threaded POSIX run-time model. This project will leverage MMU capabilities to add error detection and reporting to RTEMS.
Coverage Analysis - We want to ensure that every assembly language instruction is tested. This project will focus on moving our coverage percentage up and getting results on multiple architectures.
RTEMS BSP, Automatic Testing Framework and Nano-X For Skyeye PXA255 And EP9312 Targets - Support more thoroughly the FOSS simulator Skyeye (http://www.skyeye.org) and enable us to use it more for automated testing.
Dynamic Object File Loading - Allow systems developers to dynamically load portions of their application.
TinyRTEMS (AVR Port) - Complete the RTEMS port to the Atmel AVR and work to reduce footprint to make this an attractive option for AVR users.
Nano-X/MicroWindows for RTEMS - Multiple users have used FOSS embedded GUI systems on RTEMS but they are not in the mainstream source base. This project addresses that. This student is not a Google SoC student but funded as an RTEMS SoC student.
We are thrilled to be part of this program and will be working with our students to ensure that the code produced is of high quality and merged.
Google and the very small number of people there who make this possible really deserve a thank you. This was also the first year for Melange as the project web system and that team of three worked their fingers to the bone. Thanks.
UPS has gotten itself a lot of press over the years about how it has saved fuel, time, and money with its routing algorithms. There was recently an article in Information Week about some of their technology. It is amazing how even a small improvement can save big money AND positively impact the environment. Routing improvements save time and money. Better vehicle maintenance plans. Less idling.
This is the printable article. It has a session Id so I don't know if it will survive.
http://www.informationweek.com/shared/printableArticle.jhtml;jsessionid=34SPUBGP0QJA2QSNDLRSKHSCJUNN2JVN?articleID=212900815
This is the link with ads.
http://www.informationweek.com/story/showArticle.jhtml?articleID=212900815
The Experimental Physics and Industrial Control System (EPICS) is a set of Open Source software tools, libraries and applications developed collaboratively and used worldwide to create distributed soft real-time control systems for scientific instruments such as a particle accelerators, telescopes and other large scientific experiments.
EPICS is often used with the free real-time operating system RTEMS to build custom control systems.
Users of EPICS+RTEMS include Stanford Linear Accelerator Center (SLAC), Argonne National Labs, Brookhaven National Labs, and Canadian Light Source.
RTEMS is a free, open source alternative to VxWorks that provides POSIX threads in addition to an API we call the "Classic API" that was based upon an old dead proposed VITA standard from pSOS+ folks. RTEMS is single process, multi-threaded in the POSIX sense and has almost every POSIX 1003.1b features that is possible without being able to exec a new process. We use GNU tools and maintain an APT/Yum repository so GNU/Linux users have an easy situation with the tools. Check out some of the places it has been used at http://www.rtems.org/flyers.html and in the Wiki Applications page. You can get predictable tasking and algorithmic behavior while still staying in the free software world.
I was absolutely thrilled that RTEMS was accepted this year for the first time. As others have said, we also were not a mentoring organization in the past, so they must have evaluated the project and ideas page. We have already have some students pipe up on our mailing list and I really look forward to having some students accepted and working with them.
I asked one question on the SOC google group and have lurked there. The google folks seemed to bend over backwards answering questions. Thanks.
My machine has a bunch of stuff on it so a virgin Win2K system MIGHT have different results but I handchecked that the file's date matched the install date on the machine. So CAVEAT EMPTOR... a slightly fancier grep and some patience...
find . -type f | while read f do
strings "$f" | grep -i "Copyright " | grep -v Microsoft
test $? -eq 0 && echo $f done
showed up Thomas Lane's open source JPEG work in multiple places, Mark H. Colburn's work in system32/pax.exe, Mark Adler's PNG work in at least system32/pngfilt.dll and a few more interesting cases.
system32/offfilt.dll has Mark Adler's inflate in it.
c:\Program Files\Common Files\Microsoft Shared\VGX appears to have zlib based upon this:
RTEMS (a free embedded real-time OS) uses automake and autoconf. It is always cross compiled, supports about a dozen target CPUs,
and untold number of hosts. Autoconf'ed packages that don't cross-compile easily are a reflection on the person who applied autoconf to the package -- not autoconf itself.
Over the years, we have compiled numerous packages to target RTEMS. Some compile easily, some don't. That is independent of autoconf.
We converted a few years ago from a complex custom Makefile scheme to autoconf. We have slowly used more and more features and are now using automake as well as autoconf. One thing autoconf does nicely is keep you from figuring out which features vary. Right now, that onus is on you.
When a new OS version comes out -- you have to deal with it.
RTEMS (see http://www.oarcorp.com/RTEMS is an embedded RTOS that uses this approach. We got the idea from other "run-time" libraries in the GNU software suite. This is very similar to the exception used by the GNAT (GNU Ada) run-time. I believe there should be a special version of the GPL called something like the "Run-Time GPL" to address cases like this. There is no point in every project writing their own exception paragraph and possibly creating loopholes.
The specific paragraph we add to the GPL is:
"As a special exception, including RTEMS header files in a file, instantiating RTEMS generics or templates, or linking other files with RTEMS objects to produce an executable application, does not by itself cause the resulting executable application to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU Public License."
Be aware that if your software is useable in non-embedded systems, you might want a more
pure version of the GPL. Someone mentioned allowing the exception on systems without dynamic linking.
We have tried very hard over the past 10 years to walk a fine line between being free software for embedded systems and placing undue restrictions on those using our software. It is a tough balancing act but we like this solution. Making your own strange license requires that you explain it which is no fun either.:)
Oh the sad irony that the figures are in format based upon a software patent. See the FSF's Why
no GIFs? for details.
As an aside there is an open source OS that supports the uITRON 3.0 API and POSIX -- RTEMS.
Congratulations to all recipients. The projects are definitely worthy.
--joel
There is at least one truly free alternative
to VxWorks -- RTEMS. RTEMS has clear licensing
that frees the application from an concern over
being convered by the GPL. RTEMS, like VxWorks,
has multiple threads but no processes. RTEMS
supports about 85% of POSIX 1003.1b (remember
no processes).
The network stack is a port of the FreeBSD one
and has great performance. RTEMS has been ported
to about a dozen CPU families and supports multiple APIs (Classic/RTEID/pSOS+, POSIX, and
ITRON). See www.rtems.com for details.
Disclaimer: I am the maintainer.:)
There are a number of other free/open source RTOSes for the embedded community. RTEMS (http://www.oarcorp.com/RTEMS) is probably the oldest of these. Other alternatives include eCos (http://sources.redhat.com/ecos) and uCOS (no URL handy).
Disclaimer: I am one of the original authors and current maintainer of RTEMS.:)
Slashdot Mirror
There's no way to "verify user accounts" until they post their first content - if there was, we could automate that verification.
I have run a fan forum (phpbb) for a musician for about 7 years. At peak times we have gotten up to 50-100 spam account attempts a day. I added a captcha which does not stop everything but slows it down a lot. http://www.stopforumspam.com/ is a good resource for checking if the email or nick is a known spammer. A quick google on the nick and you can often guess based on how many hits you get and the "interests" is a good indicator. Email addresses which look like incremented numbers, pharma ads, etc. are spotted and dropped. We have seen multiple cases of countries which are sources of "cheap manual labor" as sources of semi-automated or repeated manual attempts with clearly algorithmically generated names. Given the subject matter of this forum, I felt OK blocking countries which cause too many problems. This would NOT be an acceptable solution for other forums. I don't know if someone could automate it or not but I can tell you that we are fairly reliable at not allowing spam accounts.
In know in Alabama, it is from the driver's licenses since that is a larger pool.
I have jury duty this week in Huntsville Alabama and I will be paid $10 a day plus $.05 per mile for travel to and from the court house. If I am dismissed on the first day, I get nothing. So at least here, you would make more begging or on unemployment than jury duty.
Jake.. 2009 was one of the most active years yet. The Google Summer of Code students were absolutely wonderful. I have pushed on test coverage to get as close as possible to 100%. Santosh was the GSoC student who worked with me and we got test reports near 100% on 5 target architectures (x86, sparc, powerpc, arm, and m68k/coldfire).
No problem. Different OSes for different problems. RTEMS is highly focused on systems wher predictability in execution and resource usage are valued.
RTEMS targets a different POSIX profile than GNU/Linux. RTEMS provides a single process, multi-threaded environment with either constant or predictable execution times for nearly every service. A small RTEMS system would be 64Kb total code and data space but that would not be the smallest possible. A large RTEMS system with BSP TCP/IP, filesystem, webserver, and telnetd will fit into less than 512Kb code space. This is tiny, if not impossible, for a GNU/Linux system.
The summary specifically says Linux and the article linked to doesn't expand that statement. What about running it on *BSD, Haiku, Minix, RTEMS, etc.? Reading a quote in the article carefully says "redistributors". What is a redistributor? A Novell reseller?
As a result of today's expansion of that deal, Moonlight users will enjoy protection under the patent covenant regardless of whether they're using Novell's (NASDAQ: NOVL) Linux distro or another distributor's.
"A really important change in how the community and individuals will see and use Moonlight is a change and extension to the patent covenant that Microsoft provides to Novell and its end users," Brian Goldfarb, director of Web and user experience platforms at Microsoft, told InternetNews.com. "We're now increasing the reach of the agreement -- Microsoft's commitment not to sue Novell or Novell customers now extends to redistributors."
The first sentence is the author's so reflects their interpretation. The second is a Microsoft person who uses the phrase "not to sue Novell or Novell customers now extends to redistributors". So who does that actually cover?
My limited experience caching with people with an iPhone shows about the same behaviour. So yes, some casual GPS users will go away if they have a smartphone with good mapping application but I think there is a LONG way to go before a smartphone GPS will be as good at the task as a dedicated GPS. Some shrinkage will undoubtedly occur as the "coolness" of the standalone GPS wears off and more cars get nav systems built-in. But I hope it doesn't kill the GPS manufacturers since their really is a difference. :)
I went geocaching this weekend for the first time with my G1 using GeoBeagle. I also have a Garmin 60csx which is a very nice handheld GPS. The G1's application was slower to update the distance to cache than the Garmin and would jump more than I was used to. The G1 would also lose the satellites when the Garmin wouldn't. But the G1 was very accurate, often showing 2 meters to the cache when we had found it.
Well as the maintainer of RTEMS (http://www.rtems.org)>, I am biased but there are a number of technical reasons. Deterministic (e.g. predictable or O(constant)) performance independent of the number of OS object instances in the system is a big reason. Support for priority ceiling and priority inheritance. Very low resource requirements with a minimal configuration on some CPUs starting at 16K. All software running on the target hardware appropriately licensed for use in embedded systems -- no pure GPL code. RPMs or Windows tool binaries for over a dozen CPU architectures. A project that is used to supporting software long term. RTEMS aims to be compliant with POSIX Profiles .51 and .52 as well as providing an API based upon the same standard as pSOS+ with a feature set tuned to make it easy to transition VxWorks applications. We even do automated code coverage analysis to ensure that our test suites execute as much of the OS as possible. We are currently over 97% of the binary and have a Summer of Code project working to improve that.
And RTEMS is has been on many spacecraft also from NASA, ESA and others around the world. Herschel, Planck, Electra, Venus Express, Dawn, Fermi, and THEMIS come to mind quickly. And that ignores many national laboratories around the world including Argonne,Stanford Linear Accelerator, Oak Ridge, Canadian Light Source, and Brookhaven.
RTEMS is a unique free software project that balances the needs of embedded projects that need stability and longevity with the release early and often approach of the FOSS community. We support student and hobby projects in parallel with some of the most serious projects out there. We are an open project that is 20 years old with 15 of those years captures in the CVS repository.
That's why RTEMS is a valid and very competitive FOSS alternative to VxWorks for a deeply embedded real-time operating system.
It spent years on the front of a 1987 Mazda 626 I bought new. I don't remember when I got it but it had to be before 1989. When I noticed the plate was getting rusty, I took it off and hung it in my office.
As maintainer of RTEMS, I am very proud that both spacecraft are running our free real-time operating system on at least the Spacecraft Management Unit (SMU). These are both important missions which promise to provide us with new insights.
And it runs RTEMS. There are a lot of RTEMS physics applications thanks to the EPICS community. Great group of talented folks.
We are thrilled to be part of this program and will be working with our students to ensure that the code produced is of high quality and merged. Google and the very small number of people there who make this possible really deserve a thank you. This was also the first year for Melange as the project web system and that team of three worked their fingers to the bone. Thanks.
UPS has gotten itself a lot of press over the years about how it has saved fuel, time, and money with its routing algorithms. There was recently an article in Information Week about some of their technology. It is amazing how even a small improvement can save big money AND positively impact the environment. Routing improvements save time and money. Better vehicle maintenance plans. Less idling. This is the printable article. It has a session Id so I don't know if it will survive. http://www.informationweek.com/shared /printableArticle.jhtml;jsessionid=34SPUBGP0QJA2QSNDLRSKHSCJUNN2JVN?articleID=212900815
This is the link with ads.
http://www.informationweek.com/story/showArticle.jhtml?articleID=212900815
Since you said experimental physics... :)
The Experimental Physics and Industrial Control System (EPICS) is a set of Open Source software tools, libraries and applications developed collaboratively and used worldwide to create distributed soft real-time control systems for scientific instruments such as a particle accelerators, telescopes and other large scientific experiments.
EPICS is often used with the free real-time operating system RTEMS to build custom control systems.
Users of EPICS+RTEMS include Stanford Linear Accelerator Center (SLAC), Argonne National Labs, Brookhaven National Labs, and Canadian Light Source.
RTEMS is a free, open source alternative to VxWorks that provides POSIX threads in addition to an API we call the "Classic API" that was based upon an old dead proposed VITA standard from pSOS+ folks. RTEMS is single process, multi-threaded in the POSIX sense and has almost every POSIX 1003.1b features that is possible without being able to exec a new process. We use GNU tools and maintain an APT/Yum repository so GNU/Linux users have an easy situation with the tools. Check out some of the places it has been used at http://www.rtems.org/flyers.html and in the Wiki Applications page. You can get predictable tasking and algorithmic behavior while still staying in the free software world.
I was absolutely thrilled that RTEMS was accepted this year for the first time. As others have said, we also were not a mentoring organization in the past, so they must have evaluated the project and ideas page. We have already have some students pipe up on our mailing list and I really look forward to having some students accepted and working with them. I asked one question on the SOC google group and have lurked there. The google folks seemed to bend over backwards answering questions. Thanks.
TRON is a set of standards. I know of two free implementations of the microITRON standard -- eCos and RTEMS. --joel sherrill
My machine has a bunch of stuff on it so a virgin
Win2K system MIGHT have different results but I
handchecked that the file's date matched the
install date on the machine. So CAVEAT EMPTOR...
a slightly fancier grep and some patience
find . -type f | while read f
do
strings "$f" | grep -i "Copyright " | grep -v Microsoft
test $? -eq 0 && echo $f
done
showed up Thomas Lane's open source JPEG work in multiple places, Mark H. Colburn's work in system32/pax.exe, Mark Adler's PNG work in at least system32/pngfilt.dll and a few more interesting cases.
system32/offfilt.dll has Mark Adler's inflate in it.
c:\Program Files\Common Files\Microsoft Shared\VGX appears to have zlib based upon this:
$ strings Program\ Files/Common\ Files/Microsoft\ Shared/VGX/vgx.dll | grep -i Copy
4,f deflate 1.1.3 Copyright 1995-1998 Jean-loup Gailly
f,f inflate 1.1.3 Copyright 1995-1998 Mark Adler
And Adobe Acrobat PDFWriter also uses zlib per system32/spool/drivers/w32x86/2/pdfdd.dll.
This is far from exhaustive of 100% scientfic but a good starting point.
--joel
RTEMS (a free embedded real-time OS) uses automake and autoconf. It is always cross compiled, supports about a dozen target CPUs,
and untold number of hosts. Autoconf'ed packages that don't cross-compile easily are a reflection on the person who applied autoconf to the package -- not autoconf itself.
Over the years, we have compiled numerous packages to target RTEMS. Some compile easily, some don't. That is independent of autoconf.
We converted a few years ago from a complex custom Makefile scheme to autoconf. We have slowly used more and more features and are now using automake as well as autoconf. One thing autoconf does nicely is keep you from figuring out which features vary. Right now, that onus is on you.
When a new OS version comes out -- you have to deal with it.
RTEMS (see http://www.oarcorp.com/RTEMS is an embedded RTOS that uses this approach. We got the idea from other "run-time" libraries in the GNU software suite. This is very similar to the exception used by the GNAT (GNU Ada) run-time. I believe there should be a special version of the GPL called something like the "Run-Time GPL" to address cases like this. There is no point in every project writing their own exception paragraph and possibly creating loopholes.
:)
The specific paragraph we add to the GPL is:
"As a special exception, including RTEMS header files in a file, instantiating RTEMS generics or templates, or linking other files with RTEMS objects to produce an executable application, does not by itself cause the resulting executable application to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU Public License."
Be aware that if your software is useable in non-embedded systems, you might want a more
pure version of the GPL. Someone mentioned allowing the exception on systems without dynamic linking.
We have tried very hard over the past 10 years to walk a fine line between being free software for embedded systems and placing undue restrictions on those using our software. It is a tough balancing act but we like this solution. Making your own strange license requires that you explain it which is no fun either.
Oh the sad irony that the figures are in format based upon a software patent. See the FSF's Why no GIFs? for details. As an aside there is an open source OS that supports the uITRON 3.0 API and POSIX -- RTEMS. Congratulations to all recipients. The projects are definitely worthy. --joel
There is at least one truly free alternative to VxWorks -- RTEMS. RTEMS has clear licensing that frees the application from an concern over being convered by the GPL. RTEMS, like VxWorks, has multiple threads but no processes. RTEMS supports about 85% of POSIX 1003.1b (remember no processes). The network stack is a port of the FreeBSD one and has great performance. RTEMS has been ported to about a dozen CPU families and supports multiple APIs (Classic/RTEID/pSOS+, POSIX, and ITRON). See www.rtems.com for details. Disclaimer: I am the maintainer. :)
There are a number of other free/open source RTOSes for the embedded community. RTEMS (http://www.oarcorp.com/RTEMS) is probably the oldest of these. Other alternatives include eCos (http://sources.redhat.com/ecos) and uCOS (no URL handy).
:)
Disclaimer: I am one of the original authors and current maintainer of RTEMS.