Don't see this happening scientists are totally happy installing R or Matlab etc. Often a lab even sticks with windows b/c of some drivers for a sensor that only exists for windows
One thing that I found mind blowing initially was that unbricking my pixel 5 involved simply going to Google's install page for it in Chrome with the usb connected and it reflashed successfully.
Of course, there's nothing fundamentally new there, I'm sure Java applets could have done it on a serial port if somebody tried, but it was impressive given how gimped most os-level access is in a browser.
So I would imagine you could write just enough webusb code to get new instruments to work that you wouldn't need local apps as a manufacturer.
The knife cuts both ways, though: webusb / webhid / webmidi allow raw access to physical devices which weren't designed for it, and therefore don't have any protections for it. You're just one nag screen away from having your devices be permanently hacked by some random website.
It's quite worrying seeing the Chrome team have such blatant disrespect for basic security. Rather than using an allowlist for known-good devices or using some kind of handshake to validate the device is okay with a certain website talking to it, they use a blocklist to prevent a website from messing with things like keyboards/mice/u2f keys. It's a massive footgun waiting to go off.
Firefox refuses to implement those APIs due to security concerns, and until they do a serious design overhaul it'd probably be better if Chrome hid it behind a default-off feature switch too.
> So I would imagine you could write just enough webusb code to get new instruments to work that you wouldn't need local apps as a manufacturer.
Yes, delivering device control software in a browser with webusb from a cloud platform will usher in a whole new chapter of keeping people from truly owning the scientific research equipment they have procured!
Enterprise companies have huge issues with installing, securing and maintaining open-source software though. Using browser based tools doesn't really resolve the underlying organizational and competence issues, but at least it lets people do their jobs.
From what I see helping some friends not well versed with programming doing their PhDs, FORTRAN still has a lot of penetration with scientists. Lots of climate models are FORTRAN code.
Also, through helping them I can see the dire state of scientific code, it's a mess, if departments had the budget to employ 1-2 professional programmers to help them mentor staff it could be extremely helpful for science code to be more easily shared and reasoned about, some of the code I've seen is basically throw away code after the contributors aren't around anymore...
I get the impression that you think that Fortran is a bad language for science.
Modern Fortran is a nice language for many scientific computing tasks. For me, I like Fortran because it's basically the easiest statically-typed compiled language (I rarely have to think about pointers, for instance), it's basically as fast as C, it has some good features for my variety of scientific computing (arrays in particular), and it has many compilers. Certainly, a better language could be designed without the legacy baggage and some features I'd like (better generics in particular), but I haven't seen anything better yet myself.
Now, legacy FORTRAN (note caps) is often a mess. It wasn't until the Fortran 90 standard that the capitalization changed, and the language changed a lot with that standard as well. I suspect the issues that you're seeing are more from many scientists not modernizing, and not from Fortran in itself.
A lot of scientific code is worse than a mess, it outright doesn't work and yields incorrect results, a problem which is then routinely covered up. I've seen this first hand :( The worst part is that universities don't realize how much they don't know. On the rare occasions outsiders notice what's going on they are faced with a wall of baffling excuses and justifications for why so much doesn't work, like "if it didn't crash it must be correct" or "scientists don't need unit tests, we just look at the results and know they are right because we're experts". Academics are happy to pronounce that professional coders can't judge the correctness of their work and do so loudly and publicly.
As for money, well departments do have the budgets to hire developers. Science funding is in the high billions in most western countries. The problem is not departmental budgets, it's a social problem. Universities love the practice of spreading money amongst as many professors and tiny departments as possible in order to lay claim to every possible area of human knowledge/experience. Combine that with a culture of low standards and coverups and you've got a recipe for disasters (e.g. invariably critical bug fixes that corrupt data are described as not affecting the final results even when that clearly can't be true).
exe34|2 years ago
Of course, there's nothing fundamentally new there, I'm sure Java applets could have done it on a serial port if somebody tried, but it was impressive given how gimped most os-level access is in a browser.
So I would imagine you could write just enough webusb code to get new instruments to work that you wouldn't need local apps as a manufacturer.
jaflo|2 years ago
crote|2 years ago
It's quite worrying seeing the Chrome team have such blatant disrespect for basic security. Rather than using an allowlist for known-good devices or using some kind of handshake to validate the device is okay with a certain website talking to it, they use a blocklist to prevent a website from messing with things like keyboards/mice/u2f keys. It's a massive footgun waiting to go off.
Firefox refuses to implement those APIs due to security concerns, and until they do a serious design overhaul it'd probably be better if Chrome hid it behind a default-off feature switch too.
jclulow|2 years ago
Yes, delivering device control software in a browser with webusb from a cloud platform will usher in a whole new chapter of keeping people from truly owning the scientific research equipment they have procured!
pests|2 years ago
Tarq0n|2 years ago
piva00|2 years ago
Also, through helping them I can see the dire state of scientific code, it's a mess, if departments had the budget to employ 1-2 professional programmers to help them mentor staff it could be extremely helpful for science code to be more easily shared and reasoned about, some of the code I've seen is basically throw away code after the contributors aren't around anymore...
btrettel|2 years ago
Modern Fortran is a nice language for many scientific computing tasks. For me, I like Fortran because it's basically the easiest statically-typed compiled language (I rarely have to think about pointers, for instance), it's basically as fast as C, it has some good features for my variety of scientific computing (arrays in particular), and it has many compilers. Certainly, a better language could be designed without the legacy baggage and some features I'd like (better generics in particular), but I haven't seen anything better yet myself.
Now, legacy FORTRAN (note caps) is often a mess. It wasn't until the Fortran 90 standard that the capitalization changed, and the language changed a lot with that standard as well. I suspect the issues that you're seeing are more from many scientists not modernizing, and not from Fortran in itself.
mike_hearn|2 years ago
As for money, well departments do have the budgets to hire developers. Science funding is in the high billions in most western countries. The problem is not departmental budgets, it's a social problem. Universities love the practice of spreading money amongst as many professors and tiny departments as possible in order to lay claim to every possible area of human knowledge/experience. Combine that with a culture of low standards and coverups and you've got a recipe for disasters (e.g. invariably critical bug fixes that corrupt data are described as not affecting the final results even when that clearly can't be true).
konradha|2 years ago
https://dev.lfortran.org/