<pre><code> LabVIEW 2020+
Windows 10+
Git
And tortoise git (for its embedded diff tool)
</code></pre>I'm a big fan of tortoise and mainly its revision graph. I must say their 3-way merge tool is the best free software on Windows the only competing one, but less good, is p4merge, and it's closed source.
Also Tortoise is one of the big reasons I did not switch to MacOS at work (yes, the revision graph, and no, there are no almost-as-good-or-better alternative on Linux/MacOS, but please prove me wrong) .
TIL about LabVIEW and the G programming language. Also it breaks my mental image of NASA people working on Linux or MacOS.
LabVIEW is really fantastic because it’s really easy to throw lab software together in a few hours or days and just get hardware test stands off the ground, especially when you don’t have a SWE in your department and you have an engineer who just wants to get it working and doesn’t want to get bogged down in code. It’s also pretty easy to make changes to even if you have limited software dev experience. Sure, there are many projects where you really want to have the flexibility of traditional programming languages and have actual SWEs work on it, and the proprietary license is annoying, but it makes a lot of sense when you see non-SWE engineers and techs working with it on the lab floor.
Edit: By the way I’m aware that there are LabVIEW specific SWEs as mentioned in the article who are able to do wizardry with it, but I wanted to highlight its usability beyond that.
This completely differs from my own experience with LabView, which I used a number of times in both undergrad/some grad-level coursework (I have a mechanical engineering background), as well as in internships at a couple of different companies. LabView sits, almost uniquely, in the "absolutely not, with no exceptions, ever again for the rest of my life" tools that I've worked with in my career. I don't think I even list on my resume anymore, because I don't want anyone to know that I've ever touched it and assume I'd be willing to again.
I know it's a classic "don't blame your tools!" situation, but the ability for even moderately-experienced programmers to accidentally build high-incidental-complexity tooling that becomes a nightmare to re-learn once you've lost your mental model of the program is, in my experience, unique (and frightening).
I once spent weeks trying to get a LabView-based tool up and running that a senior engineer in another section had written. Sketching out the relationships between components, documenting I/O, etc. After finally giving up the ghost, I went to that engineer for help. After spending hours (like, 5-6 hours, not 1-2) sitting next to him in my lab, he said "yeah, I'm not really sure what I was doing with this...", and proceeded to need to take the entire program back to his desk for nearly a week before he could finally explain how it worked.
This situation wasn't a one-off; it's happened with nearly every non-trivial codebase that I've ever touched that used it. In my experience, LabView is really fantastic in only two situations:
a) Very simple GUI-based DAQ tools that the person who wrote the program, and them alone, will need to use
b) Complex tools that are owned by a team of engineers who have written LabView for years and will now be dedicated exclusively to those tools
You missed a lot of its value, which the parent commenter highlighted.
Agreed, it's terrible if you have to maintain something from before, especially as over the years they get bad as one engineer after another adds or fixes one thing or another. It's terrible for that, and those codebases and tools should have been migrated to python etc. long ago.
It is great for getting a piece of hardware working and being tested today. In the next 2 hours. Sometimes you just don't have thr time or money in the budget to write custom code for everything. Sometimes you just need to make it work and move on. Labview is great for that.
Just anecdotal, but I've met a few hundred NASA contractors (and am one, and work on the field) and I'm not aware of anyone ever using MacOS as their primary OS. The laptops are all issued by the government (or a prime contractor but that's not so different in the end) and I've never heard of them issuing MacBooks
> I must say their 3-way merge tool is the best free software on Windows the only competing one, but less good, is p4merge, and it's closed source.
A long time ago, I used Araxis Merge[1] and I can strongly recommend it[2]. It was specifically better than both tortoise git and p4merge, after having used both of those options personally.
Indeed it seems to be a very good diff tool, plus the fact the license is for life.
But this is not the killer feature that will make me replace tortoise (in fact you can even configure tortoise to use an external diff tool different from theirs).
The killer feature for me is the revision graph [0], and even if tortoise is open source, I can't find something good enough on Linux/MacOS to approach the features of that said revision graph. But once again, please prove me wrong.
Indeed. My subjective perception is that NASA don't use that as much as they used to. But at least it is OSD compliant[1], and not some weird, janky "sort of Open Source but not really" license.
NOSA is an absolute pain to deal with. In particular requirement that all changes be your "original creation" has scuttled a number of efforts to integrate projects into the wider ecosystem.
This is not NASA's first open source software. NASA has released open source software for years.[1] This is just something NASA's Stennis Center is doing.
The article and its title are abundantly clear: this is NASA Stennis's first open source software. It's obviously not NASA's first piece of open source software. Are you saying that it's not Stennis's first open source release?
From an "Eats Shoots and Leaves" perspective, the following interpretation is just one interpretation: some business unit of NASA at Stennis Space Center released for its first time some software under an open source license.
Other interpretations require background information to rule out:
* NASA Stennis released NASA's first OSS.
* The first software released under an open source software anywhere has been released by NASA Stennis.
* NASA's Stennis facility has acquired AGI and its first act was an OSS release.
The last item can be ruled out by most folks since it "burys the lede" of a significant AGI development. The penultimate item can be ruled out by most people with an awareness of OSS. The first item is trickier without some knowledge of NASA as an organization and its history. For example, oftentimes things made by other organizations like JPL have a lot of NASA branding.
In some ways, the "correct" interpretation also has reason to rule it out: What is newsworthy about a facility business unit of NASA doing something its first time that the rest of the organization has been doing for a while?
I think you might be the one not getting a few things. Which would be fine and no crime except you presumed to lecture someone else from this weak position.
First off, this was a different user. Second, they are simply saying that they didn't read the title that way either originally, not that they don't grasp what has been said since. Third, it is still a perfectly valid way to parse that sentence even using your attemped re-framing.
"Foo from HN releases X" could perfectly reasonably be parsed to mean that X is coming from HN or from Foo. I left out the word "user" because that is an element you added that is not in the original title. "Stennis" is not a mere individual user with no actual relationship to NASA. The title doesn't contain enough information to indicate if Stennis is merely the agent or venue or department through which NASA released something, or is being referred to as it's own distinct entity releasing something of it's own, where "NASA" is merely something like the country it happens to live in. All that level of detail comes from the article or from just happening to already have prior general knowledge of NASA and it's sub-organizitions.
Red tape. So much red tape. It can take literally years to get permission to release code as open source within NASA. It's not the scientists - they want to release their code. It's the lawyers.
Concur that it takes time (it took 2.5-3 years for me to open source github/nasa/coda), but in my experience at JSC it wasn’t red tape, but a lack of staffing in the export office. It seems reasonable to me that some amount of review be performed before something can be open sourced, and the effort wasn’t too much on my end. It just took a long time.
I release my work at JPL routinely. The process has been streamlined a LOT in the last few years, and now it usually takes on the order of a week or so.
According to the readme https://github.com/nasa/NDAS, the pre-requisite are
<pre><code> LabVIEW 2020+ Windows 10+ Git And tortoise git (for its embedded diff tool) </code></pre>I'm a big fan of tortoise and mainly its revision graph. I must say their 3-way merge tool is the best free software on Windows the only competing one, but less good, is p4merge, and it's closed source.
Also Tortoise is one of the big reasons I did not switch to MacOS at work (yes, the revision graph, and no, there are no almost-as-good-or-better alternative on Linux/MacOS, but please prove me wrong) .
TIL about LabVIEW and the G programming language. Also it breaks my mental image of NASA people working on Linux or MacOS.
LabVIEW is really fantastic because it’s really easy to throw lab software together in a few hours or days and just get hardware test stands off the ground, especially when you don’t have a SWE in your department and you have an engineer who just wants to get it working and doesn’t want to get bogged down in code. It’s also pretty easy to make changes to even if you have limited software dev experience. Sure, there are many projects where you really want to have the flexibility of traditional programming languages and have actual SWEs work on it, and the proprietary license is annoying, but it makes a lot of sense when you see non-SWE engineers and techs working with it on the lab floor.
Edit: By the way I’m aware that there are LabVIEW specific SWEs as mentioned in the article who are able to do wizardry with it, but I wanted to highlight its usability beyond that.
This completely differs from my own experience with LabView, which I used a number of times in both undergrad/some grad-level coursework (I have a mechanical engineering background), as well as in internships at a couple of different companies. LabView sits, almost uniquely, in the "absolutely not, with no exceptions, ever again for the rest of my life" tools that I've worked with in my career. I don't think I even list on my resume anymore, because I don't want anyone to know that I've ever touched it and assume I'd be willing to again.
I know it's a classic "don't blame your tools!" situation, but the ability for even moderately-experienced programmers to accidentally build high-incidental-complexity tooling that becomes a nightmare to re-learn once you've lost your mental model of the program is, in my experience, unique (and frightening).
I once spent weeks trying to get a LabView-based tool up and running that a senior engineer in another section had written. Sketching out the relationships between components, documenting I/O, etc. After finally giving up the ghost, I went to that engineer for help. After spending hours (like, 5-6 hours, not 1-2) sitting next to him in my lab, he said "yeah, I'm not really sure what I was doing with this...", and proceeded to need to take the entire program back to his desk for nearly a week before he could finally explain how it worked.
This situation wasn't a one-off; it's happened with nearly every non-trivial codebase that I've ever touched that used it. In my experience, LabView is really fantastic in only two situations:
a) Very simple GUI-based DAQ tools that the person who wrote the program, and them alone, will need to use
b) Complex tools that are owned by a team of engineers who have written LabView for years and will now be dedicated exclusively to those tools
You missed a lot of its value, which the parent commenter highlighted.
Agreed, it's terrible if you have to maintain something from before, especially as over the years they get bad as one engineer after another adds or fixes one thing or another. It's terrible for that, and those codebases and tools should have been migrated to python etc. long ago.
It is great for getting a piece of hardware working and being tested today. In the next 2 hours. Sometimes you just don't have thr time or money in the budget to write custom code for everything. Sometimes you just need to make it work and move on. Labview is great for that.
I can see it being powerful, but having only used it in undergrad lab courses, I dislike and resent it.
Just anecdotal, but I've met a few hundred NASA contractors (and am one, and work on the field) and I'm not aware of anyone ever using MacOS as their primary OS. The laptops are all issued by the government (or a prime contractor but that's not so different in the end) and I've never heard of them issuing MacBooks
> I must say their 3-way merge tool is the best free software on Windows the only competing one, but less good, is p4merge, and it's closed source.
A long time ago, I used Araxis Merge[1] and I can strongly recommend it[2]. It was specifically better than both tortoise git and p4merge, after having used both of those options personally.
[1] https://www.araxis.com/merge/
[2] Assuming you're stuck in a windows development environment - there might be better tools available if you're not on Windows.
Araxis is the best, but not free.
Although if you maintain/contribute to an open source project they will give you a license for free.
Thanks for the tip
Indeed it seems to be a very good diff tool, plus the fact the license is for life.
But this is not the killer feature that will make me replace tortoise (in fact you can even configure tortoise to use an external diff tool different from theirs).
The killer feature for me is the revision graph [0], and even if tortoise is open source, I can't find something good enough on Linux/MacOS to approach the features of that said revision graph. But once again, please prove me wrong.
[0] : https://stackoverflow.com/a/36338943/6270743
"NASA" is extremely heterogeneous. There isn't one set of platforms or languages.
I've always wished that the Open Vehicle Sketchpad:
https://software.nasa.gov/software/LAR-17491-1
had become more popular and morphed into a general-purpose CAD program....
Interesting license:
https://raw.githubusercontent.com/nasa/NDAS/refs/heads/main/...
I wonder how the NASA copyright works given this general legal rule that US federal government works are automatically in the public domain.
I know that rule has various exceptions, but I’m left wondering exactly which of those exceptions applies in this case.
There are efforts within NASA to kill NOSA. The lawyers are the ones who insist on it.
Indeed. My subjective perception is that NASA don't use that as much as they used to. But at least it is OSD compliant[1], and not some weird, janky "sort of Open Source but not really" license.
[1]: https://opensource.org/license/nasa1-3-php
NOSA is an absolute pain to deal with. In particular requirement that all changes be your "original creation" has scuttled a number of efforts to integrate projects into the wider ecosystem.
Oh my, it's based on LabVIEW. I wouldn't have thought that NASA uses a write-only language.
be nice. (even if you're being accurate.)
This is not NASA's first open source software. NASA has released open source software for years.[1] This is just something NASA's Stennis Center is doing.
[1] https://software.nasa.gov/
The article and its title are abundantly clear: this is NASA Stennis's first open source software. It's obviously not NASA's first piece of open source software. Are you saying that it's not Stennis's first open source release?
From an "Eats Shoots and Leaves" perspective, the following interpretation is just one interpretation: some business unit of NASA at Stennis Space Center released for its first time some software under an open source license.
Other interpretations require background information to rule out:
The last item can be ruled out by most folks since it "burys the lede" of a significant AGI development. The penultimate item can be ruled out by most people with an awareness of OSS. The first item is trickier without some knowledge of NASA as an organization and its history. For example, oftentimes things made by other organizations like JPL have a lot of NASA branding.In some ways, the "correct" interpretation also has reason to rule it out: What is newsworthy about a facility business unit of NASA doing something its first time that the rest of the organization has been doing for a while?
Excuse me for being the idiot that didn't get this from the title.
HN user fshafique didn't get it.
But thats wrong! HN users gets it all the time.
See?
I think you might be the one not getting a few things. Which would be fine and no crime except you presumed to lecture someone else from this weak position.
First off, this was a different user. Second, they are simply saying that they didn't read the title that way either originally, not that they don't grasp what has been said since. Third, it is still a perfectly valid way to parse that sentence even using your attemped re-framing.
"Foo from HN releases X" could perfectly reasonably be parsed to mean that X is coming from HN or from Foo. I left out the word "user" because that is an element you added that is not in the original title. "Stennis" is not a mere individual user with no actual relationship to NASA. The title doesn't contain enough information to indicate if Stennis is merely the agent or venue or department through which NASA released something, or is being referred to as it's own distinct entity releasing something of it's own, where "NASA" is merely something like the country it happens to live in. All that level of detail comes from the article or from just happening to already have prior general knowledge of NASA and it's sub-organizitions.
My favorite NASA open source project: https://github.com/NASA-AMMOS/3DTilesRendererJS
good to see nasa keeping it open - kinda wish theyd do this more often tbh. you think old habits or just red tape stop em from going all in?
Just to be clear this is one center’s first open source release. There’s open source from other centers at https://github.com/nasa and https://code.nasa.gov/
Red tape. So much red tape. It can take literally years to get permission to release code as open source within NASA. It's not the scientists - they want to release their code. It's the lawyers.
Concur that it takes time (it took 2.5-3 years for me to open source github/nasa/coda), but in my experience at JSC it wasn’t red tape, but a lack of staffing in the export office. It seems reasonable to me that some amount of review be performed before something can be open sourced, and the effort wasn’t too much on my end. It just took a long time.
I release my work at JPL routinely. The process has been streamlined a LOT in the last few years, and now it usually takes on the order of a week or so.
I'm sure there's a joke here about the men in black wanting to slowly release all the reverse-engineered UFO operating system code.