Y2K issues were to be anticipated. Maybe not as far off as the Y2038 problem (32-bit time_t) but it was a known issue looming and getting kicked down the road. These are all just singular manifestations of using limited representations for time. The Y2038 problem bit insurance actuarial calculations years ago. Forecasts about a 30 year old's retirement trips the Y2038 problem today. The expected lifespan of a newborn tripped the Y2038 problem years ago. The horizon for the manifestation of the limitation depends on the application. Embedded systems with 20+ year life spans should have worried about Y2038 years ago.

This is not limited to Y2K and Y2038. The Boeing 787 had a time counter rollover which required a reboot every 248 days (https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fbetterembsw.blogspot.com%2F2015%2F05%2Fcounter-rollover-bites-boeing-787.html). FAA solution -- reboot every 120 days.

The Patriot Missile System had not a rollover issue but a conversion accuracy issue which led to a rapidly increasing inaccuracy in the tracking gate. (https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.cs.unc.edu%2F~smp%2FCOMP205%2FLECTURES%2FERROR%2Flec23%2Fnode4.html)

It is my experience that the inherent limits in a system's base time and interval representations is rarely considered as a risk factor in system design.

Managing time on computers is hard. Whether it is time math, time synchronisation, or just keeping an activity on a strict timeline, they all present challenges when implementing a system.

I host a forum and wiki dedicated to a musical artist with a 50+ year long career. The amount of spam and attacks is bad. Accounts to the forum require you to email the admin (on the site at the top) and ask for the magic phrase. We used to just ask a question about the artist with a 1-2 word answer. Spammers would figure it out or just find a weakness in the forum software and directly create an account. For the wiki, author accounts are done completely by hand.

I see huge amounts of traffic from certain countries and my solution is just to block IP addresses in mass from a handful of countries (e.g. Russia, China, Philippines, etc). This week I noticed that an IP in Hong Kong appears at the top of the consumers and has consumed 60GB so far this month with that being a bit under 20% by bandwidth. Positions 2-4 are bots that have Amazon IP addresses and are about 5% each or about 45GB.

Self hosting is a game of cat and mouse. I quit having a real mail service for the wiki and forum to use. I configured postfix to go through my gmail account when sending notices. Port 25 was just a constant magnet for malicious probes.

NASA successfully demonstrated laser communications a decade ago on the Lunar Atmosphere and Dust Environment Explorer (LADEE) mission. That mission included the Lunar Laser Communication Demonstration (LLCD) as a payload. They achieved over 600 Mbits/second from a lunar orbit.

https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fen.wikipedia.org%2Fwiki%2F...

At least the EUCLID Near-Infrared Spectro-Photometer (NISP) is based on the open source real-time operating system RTEMS (rtems.org). The instrument and its software is described in detail in this technical report (http://amsdottorato.unibo.it/8437/7/fornari_federico_tesi.pdf). If you poke around, you might find the Docker image they use for development on GitHub.

Anyone know of other open source projects included in the on-board software?

The SPARC ERC32, MIPS Mongoose V, and the RAD6000 all predate the RAD750. The space going SPARC line continues on with the LEON series.

In the 90s, I worked on a DoD base. All PCs had public IP addresses with no NAT. I only had dial up at home so do not remember the state of NAT at that time. By ~2000, I had Internet access at home with NAT though.

AFAIK this was all new code which would not have been exercised by existing functional tests. Best case, a static analysis tool might have flagged something but in that case a human would have had to intervene to interpret the results.

From what I can tell is an outsider who runs an open source project that is pretty old at this point, this was a breakdown in procedure by a single developer. the code should have been on a branch or made available for public review by some means. It never should have been committed to the master in the shape it was in.

There is the unfortunate side issue of pressure from the funding sponsor for the work. Along with any personal issues the developer had.

In the end, this was caught. And the code will get a lot of eyes on it. I'm not sure why they didn't start with the OpenBSD port in the beginning though. Much better starting point and more likely to have had fewer bugs introduced by the porting process.

Looks like a brilliant invention that certainly deserves a software patent. /sarcasm

Huntsville Alabama schools are currently impacted by a ransomware attack and have moved to distributing paper to students at home. This is one of multiple stories with updates (https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.waaytv.com%2Fcontent%2Fnews%2FHuntsville-City-School-system-remains-shut-down-573338271.html).

If there are lots of schools impacted, it will be interesting to see if law enforcement actually does anything about the attacks. At this point, it seems as though ransomware is a pretty low risk activity for the attackers.

RTEMS.org has been around as an open source project since the early 90s and I agree with you. It is the responsibility of the core developers to be architects, build the basic structure, and add enough value to that where others can use it but still have clear areas to contribute.

But that isn't all that is required to get contributions. You have to have low barrier to entry for both users and new developers, be nice and help them, be responsive to reviewing and merging, and have decent documentation. You have to have a focus on continuously improving that experience so it gets easier and easier. Try to avoid having different people asking the same question over and over. You aren't getting paid on a per question basis.

If you are lucky enough to have a project that requires some customization or assistance in deploying, you even have a path for some consulting revenue. Since RTEMS is a real-time operating system for embedded systems, there are always new boards, custom boards, new CPUs, new peripherals, etc. that need to be addressed for users.

Sometimes users pay for major feature additions but the core developers still need to have a roadmap and often do the groundwork for that feature in anticipation. And it is important to make it known that some features are highly desired. Having open projects and desired features available in an easy to browse form can also attract people who just want to work on some open source project or students who realize your wish list items relates to their projects or research.

It is also critical to automate as much as possible especially testing. It can become a huge time sink for things that have to be done manually and that detracts from improving the project, vetting contributions, and helps burnout people.

There has been a Toyota engine plant in Huntsville Alabama for over a decade. It surpassed 6 million engines produced in August 2018.

https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fbusinessalabama.com%2Fto...

A bit of Google magic turned up a Honda engine plant in Ohio which produces over 1 million engines annually and BMW considering plans to build a second engine plant in the US.

This is great for Linux but does it offer any protection or benefit to the FLOSS non-Linux operating systems out there? Random examples include FreeBSD, NetBSD, Haiku, ReactOS, RTEMS, HelenOS, etc.

There have been multiple public presentations about the software on this mission.

http://flightsoftware.jhuapl.e...
http://flightsoftware.jhuapl.e...

Goddard also has the interesting framework Core Flight System (cFE/cFS) which is available as open source. Again multiple presentations on it but a nice presentation by Dave McComas on it is here:

https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fntrs.nasa.gov%2Farchive%2F...

Even then, the original code may not be on GitHub. Peojexts like GCC, RTEMS and FreeBSD have the original code somewhere other than GitHub. So all of the code there for these and other projects is not original.

You are wrong on a couple of counts. GCC does support the MPC5xxx CPUs and RTEMS (rtems.org) has run on those processors for over a decade. It has been used in automotive applications. RTEMS also supports the newer qoriq CPUs with SMP support.