6 ms·

A lot of people have absolutely no problem with proprietary software until it breaks. The problem is you never know when it will break, and what it'll take down

A lot of people have absolutely no problem with proprietary software until it breaks. The problem is you never know when it will break, and what it'll take down with it. I'm not saying 'go full Stallman'. I'm just saying think that when ever you hand over your data to a private company if they consider it as important as you consider it.

baddox 13y ago
To play devil's advocate, one could say the same for a lot of open source software: it's great until it breaks. Your claim implies that broken proprietary software is bad because you can't access the source code, while mine implies that broken open source software is bad because there might be no company or organization dedicated to providing support.
- npsimons 13y ago
  Irrelevant; you can fix (or pay/trade/beg someone else to fix) FLOSS. You can't say the same for closed source.
  - baddox 13y ago
    For many things, that's only true as a technicality. Having access to the source code of a complicated piece of software doesn't instantly make it easy, or even remotely feasible, to fix it yourself. For example, back when I ran a Linux desktop and had problems with my video card or video settings, there wasn't a chance that I could fix it myself. The odds of me being able to do so were roughly equivalent to the odds of being able to fix a broken closed-source video driver by opening the binary up in a hex editor. Technically possible, yes, but not remotely feasible.
    - derrida 13y ago
      You didn't have access to the source of the video driver. Not an example of having the source being & difficult to fix.
  - nemothekid 13y ago
    How so? You could similarly beg or pay for Apple to fix the issue. Consider OP's use case. Lets say hes a non-programmer and Keynote is open source, but similar in complexity to WebKit. Now he comes across the error - what can he do? Learning to program or finding someone with the time and knowhow of Keynotes (or WebKits) inner workings may take months. On the time scale of months, he could also bitch enough at Apple that they may release a tool. However in both cases, the most time efficient solution is to download Keynote 09.
  - legulere 13y ago
    You can also patch the binaries of proprietary software, technically possible, but exactly as unfeasible as your solution when you want to get stuff done.
    - eru 13y ago
      > [...] technically possible [...] But often not legally possible?
      - userbinator 13y ago
        Practically, it's more of a "not legally possible to distribute".
- valarauca1 13y ago
  But dealing with real life probabilities the likelihood of the event occurring (Unless your approaching the fringe of newer/locked down hardware) is slim.
nols 13y ago
It's like the news that majority of the world's ATMs run on Windows XP or earlier. Or lab equipment that's air-gapped because it only works on some obsolete OS that's horribly insecure. Proprietary software is fine, but if long-lasting hardware is dependent on it bad things happen when that software company decides it's no longer worth supporting.
- valarauca1 13y ago
  The problem with airgap test equipment (I work on this kinda of stuff professionally). Is often the redevelopment of real time software for lab and calibration equipment is very expensive. Its easy to think, "Why don't they use [New Hotness Software ]?" Which on the surface seems to be a good idea. Until you absolutely need sub-millisecond precision I/O, then you kinda start to cry when you realize how hard precise timing in computers is. If you use lab equipment in say Linux, BSD, OSX, Windows. Your using a time shared, not Read-Time OS. So your I/O events aren't when the event happens, but when the scheduler is damn well ready to let you know the event happened. The easiest example is a timing equipment I was using to count digital pulses form a quartz crystal. In a 'modern' secure OS I couldn't really get below 0.1% margin of error. Which wasn't acceptable for the equipment which wasn't low enough for our uses. I fall back to an older insecure real-time platform and bumped up to 0.005%. Security is great. I attend security conferences in my spare time and try to stay up to date on the topic. The main problem is when you get into most this computing everything isn't running glibc and win32. Hacking isn't very easy unless you know the system to start with.
  - RyanZAG 13y ago
    Wouldn't it have been better to just stick a specialized piece of hardware/fpga to read directly from the crystal, buffer it, and pass it on? In fact that's what the timing equipment usually does for you. There's no reason to give up security when a few minor changes in architecture will give you performance, security and ease of maintenance and interconnectability.
    - valarauca1 13y ago
itcmcgrath 13y ago
s/proprietary// While I like non-proprietary software, there is nothing inherit that makes much of a difference for the lay person. As the complexity of the software goes up, so does the level of what is considered a 'lay person'. For any sufficiently complex software and non-pervasive problem - you're SOL in both cases. Standards help more than proprietary/non-proprietary. Lower complexity also helps more.
- dalke 13y ago
  For example, if you had your own compiler which generated a.out output, then the Linux 1.2 switch to ELF would have broken the code in a similar backward incompatible way, despite there being no proprietary code involved. (Standards wouldn't have helped either.)
  - markrages 13y ago
    Uh. # modprobe binfmt_aout # uname -rv 3.2.0-60-generic-pae #91-Ubuntu SMP Wed Feb 19 04:14:56 UTC 2014 Standards help a lot, that's why a.out still works on modern Linux.
  - pbhjpbhj 13y ago
    I'd imagine if it doesn't work though, in contrast to the OP's situation, you could spin up a virtual machine with a pre-1.2 version of Linux and run the code without having to pay anything to do so. Also this is a quite different situation to reading a document.
    - voltagex_ 13y ago
      I'm having trouble locating a (floppy?) image that old but I'd love to try - AFAICT VirtualBox was written with kernel 2.6+ in mind. Edit: Debian: http://archive.debian.org/debian/dists/Debian-0.93R6/disks/ http://archive.debian.org/debian/dists/Debian-0.93R6/disks/ RedHat: http://archive.download.redhat.com/pub/redhat/linux/1.0/en/os/i386/rootdisks/ http://archive.download.redhat.com/pub/redhat/linux/1.0/en/o...
  - npsimons 13y ago
npsimons 13y ago
In a similar vein, I'm now accelerating my plans to move to something like this: http://phpmygpx.tuxfamily.org/phpmygpx.php http://phpmygpx.tuxfamily.org/phpmygpx.php because Google has made Maps where I can no longer just paste a URL to a KMZ on another server and have it popup in maps, shareable with friends and family. It's not lockin, but it's a similar symptom of relying on software that you have no control over (closed source). I distinctly remember similar grumblings when Google shutdown Reader . . . .

baddox 13y ago

To play devil's advocate, one could say the same for a lot of open source software: it's great until it breaks. Your claim implies that broken proprietary software is bad because you can't access the source code, while mine implies that broken open source software is bad because there might be no company or organization dedicated to providing support.

npsimons 13y ago
Irrelevant; you can fix (or pay/trade/beg someone else to fix) FLOSS. You can't say the same for closed source.
- baddox 13y ago
  For many things, that's only true as a technicality. Having access to the source code of a complicated piece of software doesn't instantly make it easy, or even remotely feasible, to fix it yourself. For example, back when I ran a Linux desktop and had problems with my video card or video settings, there wasn't a chance that I could fix it myself. The odds of me being able to do so were roughly equivalent to the odds of being able to fix a broken closed-source video driver by opening the binary up in a hex editor. Technically possible, yes, but not remotely feasible.
  - derrida 13y ago
    You didn't have access to the source of the video driver. Not an example of having the source being & difficult to fix.
- nemothekid 13y ago
  How so? You could similarly beg or pay for Apple to fix the issue. Consider OP's use case. Lets say hes a non-programmer and Keynote is open source, but similar in complexity to WebKit. Now he comes across the error - what can he do? Learning to program or finding someone with the time and knowhow of Keynotes (or WebKits) inner workings may take months. On the time scale of months, he could also bitch enough at Apple that they may release a tool. However in both cases, the most time efficient solution is to download Keynote 09.
- legulere 13y ago
  You can also patch the binaries of proprietary software, technically possible, but exactly as unfeasible as your solution when you want to get stuff done.
  - eru 13y ago
    > [...] technically possible [...] But often not legally possible?
    - userbinator 13y ago
      Practically, it's more of a "not legally possible to distribute".
valarauca1 13y ago
But dealing with real life probabilities the likelihood of the event occurring (Unless your approaching the fringe of newer/locked down hardware) is slim.

nols 13y ago

It's like the news that majority of the world's ATMs run on Windows XP or earlier. Or lab equipment that's air-gapped because it only works on some obsolete OS that's horribly insecure. Proprietary software is fine, but if long-lasting hardware is dependent on it bad things happen when that software company decides it's no longer worth supporting.

valarauca1 13y ago
The problem with airgap test equipment (I work on this kinda of stuff professionally). Is often the redevelopment of real time software for lab and calibration equipment is very expensive. Its easy to think, "Why don't they use [New Hotness Software ]?" Which on the surface seems to be a good idea. Until you absolutely need sub-millisecond precision I/O, then you kinda start to cry when you realize how hard precise timing in computers is. If you use lab equipment in say Linux, BSD, OSX, Windows. Your using a time shared, not Read-Time OS. So your I/O events aren't when the event happens, but when the scheduler is damn well ready to let you know the event happened. The easiest example is a timing equipment I was using to count digital pulses form a quartz crystal. In a 'modern' secure OS I couldn't really get below 0.1% margin of error. Which wasn't acceptable for the equipment which wasn't low enough for our uses. I fall back to an older insecure real-time platform and bumped up to 0.005%. Security is great. I attend security conferences in my spare time and try to stay up to date on the topic. The main problem is when you get into most this computing everything isn't running glibc and win32. Hacking isn't very easy unless you know the system to start with.
- RyanZAG 13y ago
  Wouldn't it have been better to just stick a specialized piece of hardware/fpga to read directly from the crystal, buffer it, and pass it on? In fact that's what the timing equipment usually does for you. There's no reason to give up security when a few minor changes in architecture will give you performance, security and ease of maintenance and interconnectability.
  - valarauca1 13y ago

itcmcgrath 13y ago

s/proprietary// While I like non-proprietary software, there is nothing inherit that makes much of a difference for the lay person. As the complexity of the software goes up, so does the level of what is considered a 'lay person'. For any sufficiently complex software and non-pervasive problem - you're SOL in both cases. Standards help more than proprietary/non-proprietary. Lower complexity also helps more.

dalke 13y ago
For example, if you had your own compiler which generated a.out output, then the Linux 1.2 switch to ELF would have broken the code in a similar backward incompatible way, despite there being no proprietary code involved. (Standards wouldn't have helped either.)
- markrages 13y ago
  Uh. # modprobe binfmt_aout # uname -rv 3.2.0-60-generic-pae #91-Ubuntu SMP Wed Feb 19 04:14:56 UTC 2014 Standards help a lot, that's why a.out still works on modern Linux.
- pbhjpbhj 13y ago
  I'd imagine if it doesn't work though, in contrast to the OP's situation, you could spin up a virtual machine with a pre-1.2 version of Linux and run the code without having to pay anything to do so. Also this is a quite different situation to reading a document.
  - voltagex_ 13y ago
    I'm having trouble locating a (floppy?) image that old but I'd love to try - AFAICT VirtualBox was written with kernel 2.6+ in mind. Edit: Debian: http://archive.debian.org/debian/dists/Debian-0.93R6/disks/ http://archive.debian.org/debian/dists/Debian-0.93R6/disks/ RedHat: http://archive.download.redhat.com/pub/redhat/linux/1.0/en/os/i386/rootdisks/ http://archive.download.redhat.com/pub/redhat/linux/1.0/en/o...
- npsimons 13y ago

npsimons 13y ago

In a similar vein, I'm now accelerating my plans to move to something like this: http://phpmygpx.tuxfamily.org/phpmygpx.php http://phpmygpx.tuxfamily.org/phpmygpx.php because Google has made Maps where I can no longer just paste a URL to a KMZ on another server and have it popup in maps, shareable with friends and family. It's not lockin, but it's a similar symptom of relying on software that you have no control over (closed source). I distinctly remember similar grumblings when Google shutdown Reader . . . .