9 ms·

this kind of highlights one of the differences between FOSS and paid software. “not our fault” “too late to fix it” versus a manager forcing you to fix the da

this kind of highlights one of the differences between FOSS and paid software. “not our fault” “too late to fix it” versus a manager forcing you to fix the damn problem nobody cares whose fault it is. of course this difference is not innate, just a tendency.

jstimpfle 8y ago
Isn't it a bit cynical then that a VT100 terminal emulator and the unix shell are still my biggest productivity boost as a programmer? The Windows development environment is a terrible mess. Its command window and batch script language are barely usable. The Windows guys didn't care to fix this problem in a long long time. While Unix/FOSS platforms have traditionally been very strong in developers tooling. If you look in Windows more generally, they seem to be more wary not to break compatibility than Linux. That's because they need to run ancient programs that cannot be recompiled. I would say that "too late to fix it" is actually a problem with proprietary software, not FOSS.
- thfuran 8y ago
  Developers deciding to develop good developer tooling on a FOSS platform is about the least surprising possible outcome and doesn't really seem to have much to do with whether FOSS or enterprise is better suited to fixing a big, uninteresting problem.
- banachtarski 8y ago
  This isn't a super fair characterization. Visual Studio is miles ahead of Xcode or anything available on Linux as far as debuggers are concerned. You also have Windows Subsystem for Linux if you need it. Just because it doesn't conform to your particular workflow doesn't mean the development environment is a "mess." Personally I'm more productive in Linux for certain kinds of work, and more productive in Windows for other things (graphics work mainly, as the driver situation for GPUs on Linux is a "mess" to use your words).
  - jstimpfle 8y ago
    Yes, Visual Studio has a reputation for having the best in class debugger. While I don't know any graphical debugger for Linux that I would prefer to gdb. Other than that, Visual Studio has a reputation for being a morass slow POS. (Apparently that has gotten a little better with the latest releases). The game developers I follow all use Visual Studio exclusively for debugging. Otherwise they use a standalone editor and hand picked tooling, and batch scripts and the command window (or something like mintty which has its own problems) while cursing all the time.
    - banachtarski 8y ago
      > The game developers I follow all use Visual Studio exclusively for debugging. I work with all sorts of people in the industry across genres and I've seen plenty of workflows at many studios. I have no idea where you are getting this but you don't have any idea what you're talking about.
      - jstimpfle 8y ago
        I am talking about the game developers that I follow. I like to think that I have a good idea about the game developers that I follow. If you do it differently or know many people who do it differently, that's fine with me. I don't work in the game industry. The general statement I made was that VS is slow and that it has bugs. I also know from my own experience that this was more true in 2011 than it is now. I still don't like it.
        banachtarski 8y ago
        Out of curiosity, who do you follow?
        jstimpfle 8y ago
        Mostly Casey Muratori and Jonathan Blow. I've also watched a few streams by Abner Coimbre who now works for Jonathan Blow. And generally I like the guys from the circle of RAD Game Tools, although I'm not sure about their workflows. I believe Sean Barrett still uses Visual Studio 6.0 which is from the year 1998 according to Wikipedia.
- mehrdadn 8y ago
  > Isn't it a bit cynical then that a VT100 terminal emulator and the unix shell are still my biggest productivity boost as a programmer? The Windows development environment is a terrible mess. Its command window and batch script language are barely usable. It doesn't sound like you do Windows development? Batch files are hardly at the center of it. Things just work differently over here, and if you're gonna insist on doing things the way you're used to then there's going to be corresponding friction, just like I would if I tried Linux's GUI dev tools. Though even the CLI friction on Windows is far less now that WSL has come around. (Though PowerShell's been around for a while, which you somehow omitted.)
  - jstimpfle 8y ago
    >It doesn't sound like you do Windows development? I do, although I have only done it part time for about 16 months. And I don't do business software. I'm working on a compiler in my spare time, and on an industrial dashboard for work. Both are written in plain C (plus OpenGL and FreeType for the latter) and run under Linux as well. Command window and batch files are still way more productive for me than using a pile of junk that I don't understand, hidden behind an IDE that I cannot automate.
    - AnIdiotOnTheNet 8y ago
      "I don't want to bother learning to use the good tools, so I'll just base my opinion on all the shitty ones".
      - jstimpfle 8y ago
        Would you care to substantiate your accusations? What tools do you think are superior to approaches that let you control what happens, and do not require you to push all operations through a slow, RSI inducing, non-automatizable GUI?
        zaphar 8y ago
        You absolutely can automate the GUI. People make very good money doing exactly that. The key difference is that the barrier to doing that automation is higher than automating a CLI.
- gameswithgo 8y ago
  I'm definitely not arguing that FOSS is always worse or anything. But there are certain hard, minor usability things that tend to never get dealt with in that space. Detecting key-up fits that category. It isn't a big deal, and hard to make it happen, so it won't happen (and in this case maybe it shouldn't)
  - cryptonector 8y ago
    No it doesn't. FOSS had nothing to do with why ttys are the way they are.
- p2t2p 8y ago
  While I am much more productive in Unix command line than in GUI I still am not sure if it is real productivity boost or I just have a skill and simply used to Unix command line.
  - jstimpfle 8y ago
    The command-line is a huge productivity boost: 1) The programmer does not need to synchronize with the results displayed on screen. That's because the command-line is technically not that interactive. Input is coming from a serial line. As long as the programmer knows by heart the state transitions that his previous inputs will effect, he can simply continue typing without caring if the effected state is already displayed on screen. This is serious because typical systems can often not keep up with user input since processing is jerky and many operations simply take a certain amount of time. But GUIs with their focus based input model absolutely require that the state is updated on screen before the programmer can continue with inputs. The interpretation of inputs in GUIs is a function of the on-screen state (besides the user devices' inputs). So the serialized nature of command-lines not only saves time, but significantly reduces the stress induced upon the programmer. 2) All operations that the programmer knows how to do "interactively" can easily be combined in a script for automation. Both points are arguably missing from IDEs. The only ad
darkpuma 8y ago
There is a long history of commercial UNIX... All have the same limitation. FOSS really has nothing to do with it.
cryptonector 8y ago
Eh? No, no one can fix this. Oracle couldn't fix this in Solaris. Microsoft can't fix this either (in Windows, in Linux, not at all). It's not a question of money, or managerial will-power. You're asking to boil a great lake, and if you have the money for it, you will almost certainly find better uses for it. There is no market demand for a "fix" here, so there cannot be any managerial will-power either. Nor is this due to Unix being open source back in the 70s, because it simply wasn't open source (and save for the erstwhile OpenSolaris, it still isn't). It wasn't entirely a research vehicle either, as AT&T used Unix as the OS for its phone switches. VMS too could not have had this feature, and for the same reasons -- though I'm not familiar enough with VMS, I feel absolutely certain that VMS did not have this either. And the hardware terminals (they were all hardware terminals back then, as there were no graphical terminals in which to emulate a terminal) were decidedly not open-source, and their vendors were in it for the profit. This, and all the wonky, hacky things to do with terminals, goes back to the way things were almost half a century ago, long long before "FOSS" even came to be. Software business models have absolutely nothing to do with why you can't have key up events in ttys. EDIT: And incidentally, windowing systems happened on the scene around 1984-1985. By 1987 even SVR2 had a windowing system in the AT&T Unix PC. But it was too late to retrofit key up events into ttys -- already by then there was over a decade of legacy, and hardware terminals continued to be a thing for some time yet. This is a crucial lesson in engineering: even relatively small amounts of legacy have profound effects on what is feasible, so often you have to get things right in the very beginning (precisely when it's hardest to get things right!).
- ironmagma 8y ago
  There's a left out qualification here: "without breaking backwards compatibility". Sure, you can fix it, you just might have to change the entire stack a little bit and say goodbye to running all the programs currently out there. And then you can have a subsystem for backwards-compatibility, or in the worst case, a VM.
  - cryptonector 8y ago
    There is a ton of value in legacy. Maintaining backwards compatibility is a big deal. At some point you end-of-life a feature, but you generally don't want to make breaking changes. The tty is probably going to be with us for many more years yet (decades), so I don't see it getting end-of-lifed.
guenthert 8y ago
Uh and in commercial software you end up with a clutter of inane features, just because at one time a (potential) customer who seemed important requested it.
- reaperducer 8y ago
  Providing features that users want. So terrible.
1023bytes 8y ago
So is this possible in PowerShell? I don't think so
- AnIdiotOnTheNet 8y ago
  Actually it totally is. Because PowerShell is not a tty. https://docs.microsoft.com/en-us/dotnet/api/system.management.automation.host.pshostrawuserinterface.readkey?view=powershellsdk-1.1.0#System_Management_Automation_Host_PSHostRawUserInterface_ReadKey_System_Management_Automation_Host_ReadKeyOptions_ https://docs.microsoft.com/en-us/dotnet/api/system.managemen...
tialaramex 8y ago
It kind of does. The "paid software" will probably have some half-arsed attempt to "fix the damn problem" that makes everything awful, because a manager wasn't interested in hearing about "whose fault it is". It won't work properly, and you'll constantly be screwed over by it, but hooray, you've got "paid software" which your boss knows was able to "fix the damn problem" so there's no point even saying it can't be done, even though it can't be done - after all they paid good money, and whoever heard of a manager spending good money on a product that doesn't work... Most of you have probably used software built to this philosophy, a lot of the middle boxes for example. Most anti-virus software. Back in the day "RAM doublers". Because you may laugh at the idea of paying for software to pretend to increase your RAM rather than just actually buying RAM, but remember, "fix the damn problem". Nobody wants to hear about it being impossible, I want software that doubles my RAM, now write it...
- vardump 8y ago
  > Back in the day "RAM doublers". Because you may laugh at the idea of paying for software to pretend to increase your RAM rather than just actually buying RAM, but remember, "fix the damn problem". Nobody wants to hear about it being impossible, I want software that doubles my RAM, now write it... Some of those products actually worked. They compressed RAM instead of paging it to disk. Which was a net benefit back then, and often still is. Similar techniques are in use in modern Windows, macOS and Linux.
- izacus 8y ago
  > Back in the day "RAM doublers". Because you may laugh at the idea of paying for software to pretend to increase your RAM rather than just actually buying RAM, but remember, "fix the damn problem". Those RAM doublers fixed the "damn problem" so well, that the implementation of them now lives in Linux AND macOS kernel and is enabled by default on all Macs, Android phones and several other devices. So I think the "fix the damn problems" mentality actually works.
asveikau 8y ago
What are you talking about? "We can't fix this bug, it's not our fault, too late" is all that Microsoft, Google and Apple ever say.
reificator 8y ago
> versus a manager forcing you to fix the damn problem nobody cares whose fault it is. All I'll say on this matter is that I find your views surprising, and we'll leave it at that...
jchw 8y ago
How does this relate to FOSS? Actually, is there even demand for this to be fixed at all?
- msla 8y ago
  > How does this relate to FOSS? Anything relates to FOSS if it gets people riled up and makes the thread longer.
GuB-42 8y ago
There are lots of things Windows didn't fix in the name of backwards compatibility. And that part of what made it so successful. It is not a difference between FOSS and paid software but more about context: is fixing more important than consistency? Most FOSS is actually written by paid programmers, with grumpy managers who want that impossible problem to get fixed. If anything, the issue is that it is not always pushed back in the main line, sometimes for good reasons.
michaelmrose 8y ago
It's not impossible to fix it because its FOSS its impossible to fix it because nobody cares to invest a substantial amount of resources which is a separate but often entangled issue. It can also be too late to fix something in a deployed system because the resources required exceed the benefit derived in which case there will be no manager forcing anyone to fix anything.

jstimpfle 8y ago

Isn't it a bit cynical then that a VT100 terminal emulator and the unix shell are still my biggest productivity boost as a programmer? The Windows development environment is a terrible mess. Its command window and batch script language are barely usable. The Windows guys didn't care to fix this problem in a long long time. While Unix/FOSS platforms have traditionally been very strong in developers tooling. If you look in Windows more generally, they seem to be more wary not to break compatibility than Linux. That's because they need to run ancient programs that cannot be recompiled. I would say that "too late to fix it" is actually a problem with proprietary software, not FOSS.

thfuran 8y ago
Developers deciding to develop good developer tooling on a FOSS platform is about the least surprising possible outcome and doesn't really seem to have much to do with whether FOSS or enterprise is better suited to fixing a big, uninteresting problem.
banachtarski 8y ago
This isn't a super fair characterization. Visual Studio is miles ahead of Xcode or anything available on Linux as far as debuggers are concerned. You also have Windows Subsystem for Linux if you need it. Just because it doesn't conform to your particular workflow doesn't mean the development environment is a "mess." Personally I'm more productive in Linux for certain kinds of work, and more productive in Windows for other things (graphics work mainly, as the driver situation for GPUs on Linux is a "mess" to use your words).
- jstimpfle 8y ago
  Yes, Visual Studio has a reputation for having the best in class debugger. While I don't know any graphical debugger for Linux that I would prefer to gdb. Other than that, Visual Studio has a reputation for being a morass slow POS. (Apparently that has gotten a little better with the latest releases). The game developers I follow all use Visual Studio exclusively for debugging. Otherwise they use a standalone editor and hand picked tooling, and batch scripts and the command window (or something like mintty which has its own problems) while cursing all the time.
  - banachtarski 8y ago
    > The game developers I follow all use Visual Studio exclusively for debugging. I work with all sorts of people in the industry across genres and I've seen plenty of workflows at many studios. I have no idea where you are getting this but you don't have any idea what you're talking about.
    - jstimpfle 8y ago
      I am talking about the game developers that I follow. I like to think that I have a good idea about the game developers that I follow. If you do it differently or know many people who do it differently, that's fine with me. I don't work in the game industry. The general statement I made was that VS is slow and that it has bugs. I also know from my own experience that this was more true in 2011 than it is now. I still don't like it.
      - banachtarski 8y ago
        Out of curiosity, who do you follow?
        jstimpfle 8y ago
        Mostly Casey Muratori and Jonathan Blow. I've also watched a few streams by Abner Coimbre who now works for Jonathan Blow. And generally I like the guys from the circle of RAD Game Tools, although I'm not sure about their workflows. I believe Sean Barrett still uses Visual Studio 6.0 which is from the year 1998 according to Wikipedia.
mehrdadn 8y ago
> Isn't it a bit cynical then that a VT100 terminal emulator and the unix shell are still my biggest productivity boost as a programmer? The Windows development environment is a terrible mess. Its command window and batch script language are barely usable. It doesn't sound like you do Windows development? Batch files are hardly at the center of it. Things just work differently over here, and if you're gonna insist on doing things the way you're used to then there's going to be corresponding friction, just like I would if I tried Linux's GUI dev tools. Though even the CLI friction on Windows is far less now that WSL has come around. (Though PowerShell's been around for a while, which you somehow omitted.)
- jstimpfle 8y ago
  >It doesn't sound like you do Windows development? I do, although I have only done it part time for about 16 months. And I don't do business software. I'm working on a compiler in my spare time, and on an industrial dashboard for work. Both are written in plain C (plus OpenGL and FreeType for the latter) and run under Linux as well. Command window and batch files are still way more productive for me than using a pile of junk that I don't understand, hidden behind an IDE that I cannot automate.
  - AnIdiotOnTheNet 8y ago
    "I don't want to bother learning to use the good tools, so I'll just base my opinion on all the shitty ones".
    - jstimpfle 8y ago
      Would you care to substantiate your accusations? What tools do you think are superior to approaches that let you control what happens, and do not require you to push all operations through a slow, RSI inducing, non-automatizable GUI?
      - zaphar 8y ago
        You absolutely can automate the GUI. People make very good money doing exactly that. The key difference is that the barrier to doing that automation is higher than automating a CLI.
gameswithgo 8y ago
I'm definitely not arguing that FOSS is always worse or anything. But there are certain hard, minor usability things that tend to never get dealt with in that space. Detecting key-up fits that category. It isn't a big deal, and hard to make it happen, so it won't happen (and in this case maybe it shouldn't)
- cryptonector 8y ago
  No it doesn't. FOSS had nothing to do with why ttys are the way they are.
p2t2p 8y ago
While I am much more productive in Unix command line than in GUI I still am not sure if it is real productivity boost or I just have a skill and simply used to Unix command line.
- jstimpfle 8y ago
  The command-line is a huge productivity boost: 1) The programmer does not need to synchronize with the results displayed on screen. That's because the command-line is technically not that interactive. Input is coming from a serial line. As long as the programmer knows by heart the state transitions that his previous inputs will effect, he can simply continue typing without caring if the effected state is already displayed on screen. This is serious because typical systems can often not keep up with user input since processing is jerky and many operations simply take a certain amount of time. But GUIs with their focus based input model absolutely require that the state is updated on screen before the programmer can continue with inputs. The interpretation of inputs in GUIs is a function of the on-screen state (besides the user devices' inputs). So the serialized nature of command-lines not only saves time, but significantly reduces the stress induced upon the programmer. 2) All operations that the programmer knows how to do "interactively" can easily be combined in a script for automation. Both points are arguably missing from IDEs. The only ad

darkpuma 8y ago

There is a long history of commercial UNIX... All have the same limitation. FOSS really has nothing to do with it.

cryptonector 8y ago

Eh? No, no one can fix this. Oracle couldn't fix this in Solaris. Microsoft can't fix this either (in Windows, in Linux, not at all). It's not a question of money, or managerial will-power. You're asking to boil a great lake, and if you have the money for it, you will almost certainly find better uses for it. There is no market demand for a "fix" here, so there cannot be any managerial will-power either. Nor is this due to Unix being open source back in the 70s, because it simply wasn't open source (and save for the erstwhile OpenSolaris, it still isn't). It wasn't entirely a research vehicle either, as AT&T used Unix as the OS for its phone switches. VMS too could not have had this feature, and for the same reasons -- though I'm not familiar enough with VMS, I feel absolutely certain that VMS did not have this either. And the hardware terminals (they were all hardware terminals back then, as there were no graphical terminals in which to emulate a terminal) were decidedly not open-source, and their vendors were in it for the profit. This, and all the wonky, hacky things to do with terminals, goes back to the way things were almost half a century ago, long long before "FOSS" even came to be. Software business models have absolutely nothing to do with why you can't have key up events in ttys. EDIT: And incidentally, windowing systems happened on the scene around 1984-1985. By 1987 even SVR2 had a windowing system in the AT&T Unix PC. But it was too late to retrofit key up events into ttys -- already by then there was over a decade of legacy, and hardware terminals continued to be a thing for some time yet. This is a crucial lesson in engineering: even relatively small amounts of legacy have profound effects on what is feasible, so often you have to get things right in the very beginning (precisely when it's hardest to get things right!).

ironmagma 8y ago
There's a left out qualification here: "without breaking backwards compatibility". Sure, you can fix it, you just might have to change the entire stack a little bit and say goodbye to running all the programs currently out there. And then you can have a subsystem for backwards-compatibility, or in the worst case, a VM.
- cryptonector 8y ago
  There is a ton of value in legacy. Maintaining backwards compatibility is a big deal. At some point you end-of-life a feature, but you generally don't want to make breaking changes. The tty is probably going to be with us for many more years yet (decades), so I don't see it getting end-of-lifed.

guenthert 8y ago

Uh and in commercial software you end up with a clutter of inane features, just because at one time a (potential) customer who seemed important requested it.

reaperducer 8y ago
Providing features that users want. So terrible.

1023bytes 8y ago

So is this possible in PowerShell? I don't think so

AnIdiotOnTheNet 8y ago
Actually it totally is. Because PowerShell is not a tty. https://docs.microsoft.com/en-us/dotnet/api/system.management.automation.host.pshostrawuserinterface.readkey?view=powershellsdk-1.1.0#System_Management_Automation_Host_PSHostRawUserInterface_ReadKey_System_Management_Automation_Host_ReadKeyOptions_ https://docs.microsoft.com/en-us/dotnet/api/system.managemen...

tialaramex 8y ago

It kind of does. The "paid software" will probably have some half-arsed attempt to "fix the damn problem" that makes everything awful, because a manager wasn't interested in hearing about "whose fault it is". It won't work properly, and you'll constantly be screwed over by it, but hooray, you've got "paid software" which your boss knows was able to "fix the damn problem" so there's no point even saying it can't be done, even though it can't be done - after all they paid good money, and whoever heard of a manager spending good money on a product that doesn't work... Most of you have probably used software built to this philosophy, a lot of the middle boxes for example. Most anti-virus software. Back in the day "RAM doublers". Because you may laugh at the idea of paying for software to pretend to increase your RAM rather than just actually buying RAM, but remember, "fix the damn problem". Nobody wants to hear about it being impossible, I want software that doubles my RAM, now write it...

vardump 8y ago
> Back in the day "RAM doublers". Because you may laugh at the idea of paying for software to pretend to increase your RAM rather than just actually buying RAM, but remember, "fix the damn problem". Nobody wants to hear about it being impossible, I want software that doubles my RAM, now write it... Some of those products actually worked. They compressed RAM instead of paging it to disk. Which was a net benefit back then, and often still is. Similar techniques are in use in modern Windows, macOS and Linux.
izacus 8y ago
> Back in the day "RAM doublers". Because you may laugh at the idea of paying for software to pretend to increase your RAM rather than just actually buying RAM, but remember, "fix the damn problem". Those RAM doublers fixed the "damn problem" so well, that the implementation of them now lives in Linux AND macOS kernel and is enabled by default on all Macs, Android phones and several other devices. So I think the "fix the damn problems" mentality actually works.

asveikau 8y ago

What are you talking about? "We can't fix this bug, it's not our fault, too late" is all that Microsoft, Google and Apple ever say.

reificator 8y ago

> versus a manager forcing you to fix the damn problem nobody cares whose fault it is. All I'll say on this matter is that I find your views surprising, and we'll leave it at that...

jchw 8y ago

How does this relate to FOSS? Actually, is there even demand for this to be fixed at all?

msla 8y ago
> How does this relate to FOSS? Anything relates to FOSS if it gets people riled up and makes the thread longer.

GuB-42 8y ago

There are lots of things Windows didn't fix in the name of backwards compatibility. And that part of what made it so successful. It is not a difference between FOSS and paid software but more about context: is fixing more important than consistency? Most FOSS is actually written by paid programmers, with grumpy managers who want that impossible problem to get fixed. If anything, the issue is that it is not always pushed back in the main line, sometimes for good reasons.

michaelmrose 8y ago

It's not impossible to fix it because its FOSS its impossible to fix it because nobody cares to invest a substantial amount of resources which is a separate but often entangled issue. It can also be too late to fix something in a deployed system because the resources required exceed the benefit derived in which case there will be no manager forcing anyone to fix anything.