If it weren't for the title, I would've thought it's one of those hugely-popular-and-sometimes-shady sites with huge collections of Windows device driver downloads.
I remember doing some coding on VxWorks during my engineering school. From my then limited experience it was an oddball but also as my first exposure to hard real time programming it sure was approachable and reliable as fuck. Definitely not surprised it was picked for space stuff. Comparatively, toying with RT Linux was obscure and full of duct-tape and footguns. I wish I had a chance to try and code on QNX beyond merely booting that magical 3.5" floppy.
Oh man! That QNX floppy was _so_ awesome. (I wonder how it'd stack up today? Surely an ESP32 has more compute grunt than anything that QNX demos ran on back in the '90s, I wonder if anybody has ported it?)
My very first full-time (non-internship) professional job in the late 90's was to adapt a COTS ATM protocol stack to run on VxWorks as part of a military project featuring a satellite equipped HMMWV to provide connectivity. Part of that job was a three week trip to Alameda, CA for training and certification on VxWorks.
In general, the software worked as expected, and did what a RTOS is supposed to do in terms of being predictable and deterministic.
I applied, and _tried_ to set up a first round interview.
I had email receipts and calendar invites for an interview during my lunch break on a weekday. I was ready and available and connected to the Zoom meeting and nobody showed for an hour (which was the end of the interview slot and the end of my lunch break where I had to go back to work).
I emailed them asking what was going on, nothing back for two hours until they sent me a new calendar invite for the middle of the afternoon in my workday. I told them I couldn't make it and they canceled the interview and did not respond to several emails sent to them to try and reschedule.
Second worst Linux distro interview process after Canonical.
I've gone through it too. Twice. The 2nd time I just told them that their process sucks and they said basically "thank you for applying please don't hesitate to try again!"
I didn't even proceed when I saw what they wanted. I thought about how many people are likely to be applying to Canonical, and decided not at all worth the time.
I mean they probably filter for the kind of people that can tolerate and go through this stuff because their positions are also requiring brainless man-machines
I pretty much refuse to work at any company that has anything resembling an IQ test.
I once found myself unexpectedly being asked to take a wonderlic test, I failed the math portion on purpose then when I went into the actual interview I said roughly "haha, that math section was so hard".
My degree is in CS & Math, I just didn't want to burn the recruiter relationship.
Yes, I remember reading pretty negative comments about it. Don't remember what the complaints where about exactly. Bad license, i.e. GPL compliance? Bad support? (Why would you pay for Linux if not for support?)
Complete finger in the wind guess: Someone in the HarmonyOS post mentioned Wind River Linux next to RTLinux about an hour before this was posted. A lot of people remember Wind River from VxWorks but I'm not sure as many realized they moved on to real time Linux many years ago. Someone saw, posted. That or simply coincidence for the same reason :).
Also the HN title is actually edited and accidentally implies the wrong thing. Wind River Linux is a source only solution which has been around ages while what this page actually links to ,Wind River Linux Distro (launched in 2022), is a binary distro for certain platforms. Finger in the wind guessing says probably not the intended reason for posting given the title messes up the distinction though.
Aside: does anyone else see that hero picture and automatically know it's an AI generated pic? I seem to be developping a sixth sense for these things.
No idea but it did generate a reaction ... Is she a Hollywood spy/hacker? What system she breaking into? (Maybe it's the dark scene and backlighting :) )
Sigh, we buy their compilers for our clients on a monthly basis because the PPC and ARM support in GCC and Clang is still quite primitive.
The WR compiler generates code that is on average about 50% smaller and 30% faster last time we checked circa 2020, and it is ISO 26262 certified for a safety application.
Have you done benchmarks against other competitors? I ask because twenty years ago I used to work for Green Hills' compiler team, and we were very proud of our optimizer at the time (versus both gcc and wind river). That said, I worked on mips and various other chips, not ppc or arm.
The newer versions of the Wind River compiler is based on Clang under the hood. I wonder how the comparisons shake out vs with older versions which were more custom.
I worked on the same floor as the compiler guys and they were probably some of the best programmers in the company, them and the vxworks guys.
It takes a lot to maintain and certify a toolchain. Nevermind that the people working on it are smart people, there's a lot of process that goes into it that can only be implemented with the commercial backing of a big company behind it.
Cisco’s 64bit XR software also runs Wind River, but I can’t speak to whether it’s a hypervisor setup.
We had some routers from them that had general compute blades and those ran Wind River + QNX-based 32bit XR in a VM, but it’s pretty outdated at this point.
I myself have had the same question and never got an answer. I _think_ it's so they only have to have one build of Junos and just have to make minor changes to the Hypervisor itself to support the hardware. But who knows? Juniper have really lost their way IMHO, hypervisors on hardware designed to route traffic at scale just seems like a reflection of that fact.
Yeah seems weird but I guess the hypervisor part isn’t so odd since Citrix does it for their netscalers. Although even load balancing is probably less critical than routing traffic. I am surprised either works well under virtualization.
It's just the control plan running under Hypervisor though. The forwarding hardware is still being programmed etc, so it doesn't impact performance in that regard. For things like BGP convergence etc they've introduced it so that BGP gets sharded so that it scales better.
In a past job, I had to pick up and maintain an embedded system running Wind River Linux. Their build system was a complete dumpster fire. I have never seen a bigger pile of unorthodox custom build scripts. I would never touch their products again.
From my experience (from a few years back but still appears to be the case) is that Wind River is just wrapping Yocto these days. There could be value for some orgs where they don't have engineering teams if they do a contracting arrangement but I think, generally, orgs are better building directly on Yocto (or BuildRoot) without a vendor in the middle (other than your SoC vendor and their support layers). I'd save your money and pay for a seasoned embedded linux expert or three if you are maintained a connected product.
For smaller deployments, I think it makes more sense to look into solutions like mender.io, etc. for updates/fleet mgmt/etc.
>orgs are better building directly on Yocto (or BuildRoot) without a vendor in the middle
Going on a tangent here, but does anyone else also agree that BuildRoot is much, much nicer to work with as a dev than Yocto? I've had to work with both and BuildRoot was easy, just like building a Linux kernel with 'make menuconfig', whereas Yocto was downright painful.
Not a real expert with those systems, but I have used both. I believe buildroot is much smaller (as in much less binaries can be built) than Yocto. Yocto has its learning curve, but there is a lot readily available and you can do a lot more. It's extensible by desgn. You can build basically everything, but not without understanding the principles by just searching a few odd SO answers.
I have used buildroot for an initramfs. If you have configured a kernel before, you get going in an afternoon.
I worked with Yocto for about 8 years and about as much with buildroot.
They both get the job done but I find that yocto recipes are more tractable. You see clearly what comes from the main git tree and what patches a vendor adds on top.
I've seen some really ugly chimeras built with buildroot as a base..
The main problem of buildroot is the fact you need to rebuild from scratch all the time. Yocto has properly working incremental builds.
Yocto is definitely more flexible, which can be a curse as it gives architecture astronauts more chances to split up all the stuff it several repos and dozens of files.
In the 2006-2009 timeframe, I worked at a company where I replaced this unwieldy monstrosity with a from-scratch distro + toolchain.
It was an incremental approach. For a while, we kept running Wind River, but I replaced glibc with one I built completely not using anything from Wind River, and eventually all packages, config files and scripts in rootfs, and the kernel, until there was nothing left of Wind River.
At that time, those WR clowns hadn't figured out how to build a cross-compiled Bash that had job control. Everyone was relieved when they could use Ctrl-Z suspend and fg/bg on the target with our home spun package.
Funny thing is, that startup spent about a year looking for someone to do all this, while I worked on some C++ application stuff. Then they realized the person works there already.
Didn't Wind River have some awful build process that stitched together files from disparate fragments? Or something? My memories are fuzzy.
On this project, I had the idea of doing all patching of packages with Quilt. Yocto does that now. Years later when I had to add some patch to a Yocto package, I went into the build directory and, oh, lookie, I already know how to do this with my eyes closed.
I made ever single package cleanly cross-compile for MIPS: no Qemu on the build machine. A co-op student came on board, who was into Macs; he pretty easily got everything to build under MacOS.
I actually worked on the Wind River Linux team for a couple of years. The distro as a whole is not bad actually. Especially since it switched to Yocto.
I found that most of the actual issues we were having were due to the BSPs we were pulling in from other vendors. And WRL supported/probably still does _a lot_ of BSPs from _a lot_ of vendors for _a lot_ of architectures.
There are not that many commercially supported _embedded_ linux distributions. And WRL worked quite well for the vast majority of its customers. And I am proud to have had the honor of working with a lot of smart people there too.
My favorite part of the whole experience was that when breakage did happen, it was super quick to fix and get it into mainline. It was the first time I saw such a streamlined release process. Other companies had a release process so convoluted that it would take over half a year for a fix of mine to reach the customer.
69 comments
[ 3.3 ms ] story [ 138 ms ] thread[0]: https://jungo.com/windriver/
But to their credit, it's running on Mars, on (at least) Pathfinder, Spirit, Curiosity, and Opportunity.
Meeting, and in most cases seriously exceeding planned mission lifetimes, earns VxWorks some serious kudos from me.
In general, the software worked as expected, and did what a RTOS is supposed to do in terms of being predictable and deterministic.
I got contacted by a previous manager to apply.
I applied, and _tried_ to set up a first round interview.
I had email receipts and calendar invites for an interview during my lunch break on a weekday. I was ready and available and connected to the Zoom meeting and nobody showed for an hour (which was the end of the interview slot and the end of my lunch break where I had to go back to work).
I emailed them asking what was going on, nothing back for two hours until they sent me a new calendar invite for the middle of the afternoon in my workday. I told them I couldn't make it and they canceled the interview and did not respond to several emails sent to them to try and reschedule.
Second worst Linux distro interview process after Canonical.
Give us your high school GPA and write all of these essays and bla bla bla. Then they ghost you.
I once found myself unexpectedly being asked to take a wonderlic test, I failed the math portion on purpose then when I went into the actual interview I said roughly "haha, that math section was so hard".
My degree is in CS & Math, I just didn't want to burn the recruiter relationship.
Nice campus with private offices, pool tables and such, countered by less than stellar management.
Also the HN title is actually edited and accidentally implies the wrong thing. Wind River Linux is a source only solution which has been around ages while what this page actually links to ,Wind River Linux Distro (launched in 2022), is a binary distro for certain platforms. Finger in the wind guessing says probably not the intended reason for posting given the title messes up the distinction though.
The WR compiler generates code that is on average about 50% smaller and 30% faster last time we checked circa 2020, and it is ISO 26262 certified for a safety application.
(From the "Our History" section of this page: https://www.windriver.com/company )
Aptiv PLC is the automotive tech company that grew out of the GM spin-off, Delphi Automotive Systems, btw: https://en.wikipedia.org/wiki/Aptiv
It takes a lot to maintain and certify a toolchain. Nevermind that the people working on it are smart people, there's a lot of process that goes into it that can only be implemented with the commercial backing of a big company behind it.
https://community.juniper.net/discussion/srx1500-will-not-bo... [For example]
We had some routers from them that had general compute blades and those ran Wind River + QNX-based 32bit XR in a VM, but it’s pretty outdated at this point.
https://www.cisco.com/c/en/us/products/collateral/routers/as...
For smaller deployments, I think it makes more sense to look into solutions like mender.io, etc. for updates/fleet mgmt/etc.
Going on a tangent here, but does anyone else also agree that BuildRoot is much, much nicer to work with as a dev than Yocto? I've had to work with both and BuildRoot was easy, just like building a Linux kernel with 'make menuconfig', whereas Yocto was downright painful.
I have used buildroot for an initramfs. If you have configured a kernel before, you get going in an afternoon.
They both get the job done but I find that yocto recipes are more tractable. You see clearly what comes from the main git tree and what patches a vendor adds on top.
I've seen some really ugly chimeras built with buildroot as a base..
Yocto is definitely more flexible, which can be a curse as it gives architecture astronauts more chances to split up all the stuff it several repos and dozens of files.
It was an incremental approach. For a while, we kept running Wind River, but I replaced glibc with one I built completely not using anything from Wind River, and eventually all packages, config files and scripts in rootfs, and the kernel, until there was nothing left of Wind River.
At that time, those WR clowns hadn't figured out how to build a cross-compiled Bash that had job control. Everyone was relieved when they could use Ctrl-Z suspend and fg/bg on the target with our home spun package.
Funny thing is, that startup spent about a year looking for someone to do all this, while I worked on some C++ application stuff. Then they realized the person works there already.
Didn't Wind River have some awful build process that stitched together files from disparate fragments? Or something? My memories are fuzzy.
On this project, I had the idea of doing all patching of packages with Quilt. Yocto does that now. Years later when I had to add some patch to a Yocto package, I went into the build directory and, oh, lookie, I already know how to do this with my eyes closed.
I made ever single package cleanly cross-compile for MIPS: no Qemu on the build machine. A co-op student came on board, who was into Macs; he pretty easily got everything to build under MacOS.
I found that most of the actual issues we were having were due to the BSPs we were pulling in from other vendors. And WRL supported/probably still does _a lot_ of BSPs from _a lot_ of vendors for _a lot_ of architectures.
There are not that many commercially supported _embedded_ linux distributions. And WRL worked quite well for the vast majority of its customers. And I am proud to have had the honor of working with a lot of smart people there too.
My favorite part of the whole experience was that when breakage did happen, it was super quick to fix and get it into mainline. It was the first time I saw such a streamlined release process. Other companies had a release process so convoluted that it would take over half a year for a fix of mine to reach the customer.
Also, what do they utilize from FCOS?