Here’s an article that I think may interest some of the people here:
25 Likes
The security implications of this should be obvious to anyone, yet government organizations, while adhering minutely to security rituals with questionable efficacy, permit their installation.
Well articulated, I especially like the phrase “security rituals”. Parallel to but distinct from “security theatre”.
Both aim to give the appearance of security and considered caution (with dubious match to reality), but security theatres are targeted down at the general public, whereas security rituals are targeted up towards management and the legal system.
2 Likes
I like that the article maintains a pragmatic thread throughout: it’s not just a theoretical argument, you give pratical advice and pointers at every stage to the tools available and their scope.
In that pragmatic spirit, one thing I’d like to have seen is some small discussion of the features/toolboxes/libraries that are the attraction of proprietary tools for a lot of researchers, and how to replace them.
There’s some inertia here - the free software side has come leaps and bounds in the last couple decades, but many researchers are stuck with their old belief that the libraries they need are only in proprietary software. But there’s also some genuine differences still, depending on the fields or the particular features required.
(As an aside, this article comment section seems to be LWN at its best, with genuine discussion and thoughtful replies to a more-than-usual level.)
1 Like
Sticking with proprietary software isn’t just inertia, proprietary software has a financial sustainability advantage over FOSS. It’s not great when a widespread dependency suddenly can’t keep up with the ecosystem because the development team needed different jobs to pay the bills. There’s no shortage of FOSS with robust finances, often via ties to tech companies that use it, but there’s also tons of proprietary software that rely on sales. I don’t think anybody prefers to pay period, but when there are stakes, they’d choose faster improvements and longer product lifespans, and that more often than not involves payment.
7 Likes
…semi-comical sight of someone running around knocking on office doors, trying to find out who was using (or had left running) a copy of the program that they desperately needed to use to meet some deadline—but were locked out of.
Now imagine somebody took a company’s car and didn’t bring it back, while you desperately need it. I don’t see any difference. In both case it is just the responsibility of the company to establish processes for that not to happen.
- Ease of use, which includes
– support,
– documentation,
– user interface, esp. GUI, - Commitment by the software vendor
Concerning ease of use: Even if the autor of a package really invests his time into documentation (which many don’t), not always he’d be able to get it well. Technical writer is quite a different profession from software developer. User interface designer is still another one. Companies have such people.
Anybody has a reasonable replacement to Origin for plotting?
P.S. I definitely didn’t mean Origin as an example of great software.
1 Like
Relevant to this discussion is The Value of Open Source Software:
According to their research, firms would have to spend 3.5 times more on average if FOSS did not exist. Reinventing the wheel on every business would be a major waste of resources.
The main message of the article is that it is hard to estimate the value of FOSS because it is calculated as p\times q where p is the price (=0 in FOSS) and q is the number of users (=unknown in FOSS). They relied on side-results of license compliance checks (scripts that check for license in source code) to estimate these numbers.
4 Likes
I think you can check LabPlot and Veusz, but I don’t know if they are similar to Origin or not.
LabPlot I’ve tried long ago. With LabPlot2 I’ve put recently a reasonable effort (watching tutorials, reading docs) into trying to learn it, but we finally gave up, with my colleague going back to Excel.
Actually we don’t need much more than simple line and scatter plots for internal use, and occasional simple fitting. With LabPlot2 it was not impossible, but pain, well … in all suitable parts of the body. I can’t tell now what specifically it was, it was just a death by thousand cuts.
Veusz - thank you, I’d try it out.
Already done. It wouldn’t open on Mac - app not signed, no way.
surely I know, it’s not fair, as Origin is Windows only anyway
The difference is that it’s an artificially imposed restriction decided upon in a boardroom (and often imposed in rather fragile ways) in the case of software. It’s more like if Elon Musk decided that only one person per household is allowed to drive at a time, and so your car won’t start because your wife is out driving hers.
If it was the condition by the contract - I find that perfectly OK. Either you pay the second license, or go by feet. Which is free and healthy.
You know, the software companies somehow need to pay developers’ salaries - thank God not everyone yet is paid by the governments here.
Now installed Veusz under Ubuntu. From the first impressions, it looks usable. @linwaytin, thank you.
Glad to know that. I don’t know when you tried LabPlot, as I also have the impression that it was not quite usable. It seems they made a lot of progress recently, but whatever floats your boat!
Now, after spending some time with both LabPlot (now renamed and rewritten under the name LabPlot2) and Veusz, I think comparison of both could be quite instructive.
First we (I and my colleague), have found LabPlot not really usable, whereas Veusz, while definitely not perfect, limited, and taking some time to get used to it, can actually be used in a typical workflow of an engineer or experimental scientist: Plot data (usually scatter or line XY plot), fit them, compare plots, export plots for a report or presentation, all that without spending too much time on secondary details. Much more is possible with both apps, but I’m mostly interested in basic things.
This subjective judgement is the premise for the following comparison.
LabPlot is backed by KDE. I’m not sure how many people on the whole took part in the development, but judging alone by the fact that it is localized to 36 languages (including Sanskrit and Esperanto) - quite a lot.
The bus factor of Veusz is 1. ONE. The software is being developed since >20 years by a single person, who is doing astrophysics for his day’s job. Sure, there were a couple of other contributions, but most is done by just one person. The downloads are not signed, because it would cost like 100$ for Apple and 60$ for MS p.a. And yes, no, however unfair it is towards monolingual Sanscrit speakers - there are no localizations.
Strangely enough, the obligatory xkcd comic was not yet cited here - now here it is 
2 Likes
Did you use Veusz with Julia output data? If so how did you make the communication between both apps?
And, then, would you think a Veusz.jl package as a graphics backend (don’t know if it is easily feasible) would be interesting for your workflow?
Well, I was speaking about
typical workflow of an engineer or experimental scientist
which is the same person on the same job in my case 
. That means, I have no “Julia output data”, I only have some data from a logger, and some hand-filled Excel data. Veusz can read CSV in any case, HDF5 being in principle another option for data exchange.
Now, I was speaking about GUI-based FOSS, because of this:
and plotting data is something which is probably the second most common workflow between all kinds of sciences (writing the texts being on the 1st place), and a GUI is the pre-requisite for at least 90% of researchers and engineers (the folks here are not representative by definition). Well, it is practically a pre-requisite for 90% of experimental chemists I know, and I guess the percentage will be the higher, the farther a science is from the Physics.
Also, on my current job I don’t have access to Origin, and the lack of a suitable replacement was my/our personal pain point.
Veusz is Python-based, extendible, able to read data streams in some way - maybe it could be somehow combined with Julia. To be honest - no idea.
As a fairly frequent Veusz user, I doubt the result is worth the effort.
For graphical backend, I don’t see advantages over Makie which is better integrated with Julia in any case. But if needed, Py[thon]Call may already be enough to use Veusz scripting interface because it’s pure Python (didn’t try as I only use it for GUI).
However, it is hard to think of a practical advantage of the latter option over just using Makie. The only one I can think of is to save the plot as an editable .vsz file for sharing with coworkers.
2 Likes