4 ms·

Sure. Neither is the hardware, nor is Intel’s or the Motherboard’s, etc. Would it be ideal? Sure. Is it possible to have every level be completely open source?

Sure. Neither is the hardware, nor is Intel’s or the Motherboard’s, etc. Would it be ideal? Sure. Is it possible to have every level be completely open source? Maybe, but you’d struggle. I still believe the point is clear, though.

kgwgk 7y ago
Ah, you're right! The whole stack is open source if you ignore the non-open-source parts. (Intel compilers are also popular, by the way.)
- LolWolf 7y ago
  Look, the point here is to be as open as it is to be practical. In my lab, we attempt to use as much open source software and parts as is possible without literally spending years waiting for RISC-V to become mainstream along with fully open source GPUs and computing cores, open motherboards, RAMs, etc... this doesn't even include fabrication or other useful software which runs our machines (do you want to have a several-million-dollar photolithography machine running on poorly maintained OSS?). Yes, should that machine be open in a perfect world? Of course, that would be incredible and in the spirit of verifiability. But right now it is not and there is little we can do about it. It's clearly impossible (or completely and utterly impractical) to pretend that somehow everything can be done in a fully open source way, and it's easy to go down the rabbit hole pretending to be on the high horse of "our stuff is more open." My point is that what can be made with OSS, we almost always attempt to make with OSS, not everything we make is perfectly open and transparent, because it literally cannot be without so much effort as to render the entire thing completely useless. So, sure we use Mathematica in some things when the OSS alternative is mostly unworkable or unusable, but by and large we attempt to be as open as possible such that people can verify our results without needing to spend thousands of dollars on software whose internals we don't generally know. Do we rely on Intel software and hardware which could have another floating point bug? Sure. But it's hard to be at all productive if you don't at least assume a bare minimum, even if that standard is not completely open.
brobdingnagians 7y ago
But I'm not so sure it would be ideal. There are things which thrive better as closed source. I prefer closed source IDEs, they tend to be better designed with better long term vision. Most open source projects suffer from a lack of long term vision, tight design, and funding. There are some which do well in those, but not the majority... There are quite a few things that thrive better as closed source which would have little chance as open source projects. Proprietary closed source has a built in mechanism for funding. That's a major plus.
- AsyncAwait 7y ago
  > I prefer closed source IDEs, they tend to be better designed with better long term vision. Like Intellij?
  - ras_west 7y ago
    https://plugins.jetbrains.com/plugin/7232-wolfram-language https://plugins.jetbrains.com/plugin/7232-wolfram-language
jforberg 7y ago
No, your point is still extremely muddled. Cuda and Wolfram are both compilers/runtimes, they fill exactly the same role of translating high-level code into something that can run on hardware.

kgwgk 7y ago

Ah, you're right! The whole stack is open source if you ignore the non-open-source parts. (Intel compilers are also popular, by the way.)

LolWolf 7y ago
Look, the point here is to be as open as it is to be practical. In my lab, we attempt to use as much open source software and parts as is possible without literally spending years waiting for RISC-V to become mainstream along with fully open source GPUs and computing cores, open motherboards, RAMs, etc... this doesn't even include fabrication or other useful software which runs our machines (do you want to have a several-million-dollar photolithography machine running on poorly maintained OSS?). Yes, should that machine be open in a perfect world? Of course, that would be incredible and in the spirit of verifiability. But right now it is not and there is little we can do about it. It's clearly impossible (or completely and utterly impractical) to pretend that somehow everything can be done in a fully open source way, and it's easy to go down the rabbit hole pretending to be on the high horse of "our stuff is more open." My point is that what can be made with OSS, we almost always attempt to make with OSS, not everything we make is perfectly open and transparent, because it literally cannot be without so much effort as to render the entire thing completely useless. So, sure we use Mathematica in some things when the OSS alternative is mostly unworkable or unusable, but by and large we attempt to be as open as possible such that people can verify our results without needing to spend thousands of dollars on software whose internals we don't generally know. Do we rely on Intel software and hardware which could have another floating point bug? Sure. But it's hard to be at all productive if you don't at least assume a bare minimum, even if that standard is not completely open.

brobdingnagians 7y ago

But I'm not so sure it would be ideal. There are things which thrive better as closed source. I prefer closed source IDEs, they tend to be better designed with better long term vision. Most open source projects suffer from a lack of long term vision, tight design, and funding. There are some which do well in those, but not the majority... There are quite a few things that thrive better as closed source which would have little chance as open source projects. Proprietary closed source has a built in mechanism for funding. That's a major plus.

AsyncAwait 7y ago
> I prefer closed source IDEs, they tend to be better designed with better long term vision. Like Intellij?
- ras_west 7y ago
  https://plugins.jetbrains.com/plugin/7232-wolfram-language https://plugins.jetbrains.com/plugin/7232-wolfram-language

jforberg 7y ago

No, your point is still extremely muddled. Cuda and Wolfram are both compilers/runtimes, they fill exactly the same role of translating high-level code into something that can run on hardware.