Sujet : Re: 32 bits time_t and Y2038 issue
De : invalid (at) *nospam* invalid.invalid (Grant Edwards)
Groupes : comp.arch.embeddedDate : 21. Mar 2025, 14:27:29
Autres entêtes
Organisation : PANIX Public Access Internet and UNIX, NYC
Message-ID : <vrjpg1$4lt$1@reader1.panix.com>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
User-Agent : slrn/1.0.3 (Linux)
On 2025-03-21, Michael Schwingen <
news-1513678000@discworld.dascon.de> wrote:
I have the same experience, about 20 years ago - the company was
using a cygwin-based cross-gcc + make (I think some old borland
make) on windows. I converted the makefiles to use GNU make on
linux, and compile time was half that of the windows setup. That
speed advantage was enough to (very) slowly convert colleagues to
use Linux.
I support a product (ARM w/ RTOS) for which we put together an SDK
that allowed customers to write custom firmware. The SDK was
available for Windows+Cygwin and Linux. We had a half-dozen customers
actually use the SDK to write custom firmware. They all chose to go
the Windows+Cygwin Route. A few of them ended up maintaining their
firmware for a fairly long period of time. Eventually, keeping Cygwin
working on the customers machines, and the SDK working on Cygwin
became too much hassle. We pointed them to instructions on installing
Ubuntu on a VM inside Windows.
There were all amazed at
1. How much less work installing Linux was than installing and
troubleshooting Cygwin.
2. How much faster a build ran under a Linux VM on Windows than it
did under Cygwin on Windows.
3. How convenient it was to be able to just archive the VM image so
that the next time they needed to modify the firmware all they had
to do was plop the VM image on whatever host machine they had
handy.
Previously, they always seemed to lose track of their Windows/Cygwin
development machine and would have to reinstall Cygwin and the SDK
every time they wanted to change something (changes were usually
several years apart).
So we stopped supporting the Cygwin version of the SDK. There are
couple customers that are still maintaining their custom firmware
after 20 years. I believe they've figured out how share a directory
between Windows and the Linux VM, so they do all of their editing
under Windows, and then just do a "make" in the Linux VM, then use
tools under Windows to install/deploy the firmware. I told them they
could even run the "make" via ssh from whatever Windows IDE/editor
thingy they were using so that it could parse the make output and do
nice IDE type stuff with it, but I don't know if they ever did that.