OS is useless without applications. Linux was obscure little toy, until it took off on x86 as application support grew.
You need to recompile every single piece of crap on every platform. Including applications..
So when Linux core was ported to DEC Alpha, that was initially more development system than OS usable by end users.
And scopes are vastly more different than computers that are nowadays wery architecturally similar. Unlike LeCroy scopes and Keysight Infiniivision for instance...
There is this minor detail you have overlooked. There were all the Minix utilities and a lot of Gnu utilities already available in source format as well as a pretty staggering amount of other stuff available as source. Of course, you did have to know how to edit Makefiles and resolve library dependencies, *nix version quirks and such.
I missed the Linux announcement on comp.os.minix because I got laid off and lost Usenet access. No matter. I'd bought a Sun 3/60 and spent days compiling the Gnu utilities and a lot of other stuff like Octave and gnuplot. So there is nothing theoretical about it. On my first contract job I maintained a huge suite of Gnu and other utilities on 6 different platforms, SunOS, IRIX, CLIX, AIX, Ultrix and HP-UX which were NFS automounted everywhere. This was just a Swiss Navy project I started on my own. I got a nice email from an admin about a year after I left.
He had to do this massive update of admin tables across all these different systems and was dreading the task. "But Reg had been here and expect was everywhere". Instead of spending half the night he was done in an hour or less.
I wore out that T shirt 20 years ago. I was the guy everyone went to when their code would not compile on their new computer during the workstation wars of the late 80's and early 90's.
Have Fun!
Reg
What is missing from the software?
I am missing the ability to trigger on CAN FD frame with ID 0x18FDxx32 and byte 59 containing the pattern x11x111x. Two beers are on me, trappist or otherwise.
One thing is installing linux on a machine. Another thing is creating the device drivers that are needed to address the specific HW of that machine.
If the scopes that we usually talk about in this forum were so "universal" we didn't need to buy them! We would be using the processor development boards running our "magical" FOSS.
Everyday a new thread is created with "scope wars" because they have different HW! It's not only the software. The secret of a scope is precisely the interaction between the HW and its SW.
And many here state that they can't understand why vendors don't correct their bugs fast enough (or immediately...). It's not difficult to imagine that, if it isn't easy enough for their programmers to do so, how can someone, who was not involved in the design and architecture of the SW/HW, expect to create a software (from scratch) that will drive such HW (in a reasonable amount of time)??
And many here state that they can't understand why vendors don't correct their bugs fast enough (or immediately...). It's not difficult to imagine that, if it isn't easy enough for their programmers to do so, how can someone, who was not involved in the design and architecture of the SW/HW, expect to create a software (from scratch) that will drive such HW (in a reasonable amount of time)??
Here's one for ya Ed;
Cascading DSO's for multi channel work with an I/O to I/O on another and some method of nulling delay times so scope displays can be aligned in time for 6/8/12/16 channel operation.....not MSO.
Edit to add
First DSO in the line assumed as master as it's triggered on a trace of interest with any further DSO's displays time aligned.
Which part of your post is not exactly proof of what I am saying?
I don't want to waste my time compiling parts of OS. I don't want to waste time to maintain huge suite of GNU utilities.
I'm not a programmer. I don't want to waste time compiling Octave for my computer. I want to use Octave to calculate things for my projects. And if you're smart, you get a Windows or mainstream Linux distro and all of these things are ready to use.
You obviously are a programer and do it well. To me it is waste of time.. I have other things to do. And by that I don't think it's something beneath me. No, it simply something I don't do. It's not my job.
And many here state that they can't understand why vendors don't correct their bugs fast enough (or immediately...). It's not difficult to imagine that, if it isn't easy enough for their programmers to do so, how can someone, who was not involved in the design and architecture of the SW/HW, expect to create a software (from scratch) that will drive such HW (in a reasonable amount of time)??Well, that problem is more of a resource problem than a technical issue. In the end an oscilloscope is developed & produced to make money. If too much time is spend on a product which doesn't make a profit then the company won't survive. This means that at the technical side the software & hardware has to be easy to maintain and scalable. So rest assured that oscilloscope manufacturers are not using extremely obfustigated ways to make the hardware interact with the software. But it is hard to come up with a good architecture. A company like Siglent likely has started from scratch 3 times (if not more) to get where they are now.
I think the OP's comparison with consumer routers is forgetting that nearly all of the work had already been done for these groups. Linux already exists, and it can route packets. DD-WRT et al is mostly an exercise in cross porting and UI, the overwhelming portion of functional code in use comes from the mainline Linux distribution underneath.
A scope won't be like that. You get Linux for the core device handling, but you essentially need to start from scratch to deal with all of the functionality of a scope.
Do-able? Sure, if you have a large team and several years. It's a much larger undertaking than a router.
As with Linux, it starts with one man. (Not me! I'm only the piano player)
I think the OP's comparison with consumer routers is forgetting that nearly all of the work had already been done for these groups. Linux already exists, and it can route packets. DD-WRT et al is mostly an exercise in cross porting and UI, the overwhelming portion of functional code in use comes from the mainline Linux distribution underneath.
A scope won't be like that. You get Linux for the core device handling, but you essentially need to start from scratch to deal with all of the functionality of a scope.
Do-able? Sure, if you have a large team and several years. It's a much larger undertaking than a router.
But for Rigol/Siglent, I'm not sure it's energy well spent, given the investments made by the manufacturers and the complexity/functionality of the existing firmware