3 ms·

I agree with author prediction, however I propose another solution: Plan9. It's devs foreseen today's problem and start to solve them, far better than actual pa

by xte 8y ago

I agree with author prediction, however I propose another solution: Plan9. It's devs foreseen today's problem and start to solve them, far better than actual partial solutions. Oh, of course, Plan9 imply user independence and sovereignty a bad things for today's "industry" so Plan9 solution rest buried in the past.

rakoo 8y ago
Plan9 sure is a marvel of engineering because all interactions amount to reading/writing a specific file, but it doesn't solve the issue that is interoperability: it merely defines a way to connect to the remote service, but it doesn't say what the functional interface is. - what "files" should I read from or write to ? - what format should I use ? - when should I interact with said files ? Is it ok to tail -f it or should I reopen it every time I want to get some new information ? XML in itself didn't solve anything, it's the standards over how to define a grammar and validate it that made all the interoperability.
- xte 8y ago
  IMVHO there is a unnoticed problem underneath, probably best explained by XKcd standard's vignette (927), we will NEVER really accept for long time "proposed solution" but we can converge by nature to a common solution if we find a comfortable common way to move. Plan9 for me is an answer because yes, it does not solve problems you rightly pointed out, but instead offer a common ground to reduce them by nature. It offer a dramatically simple and effective "networked" solution so a good ground on top of which we can develop a future of IT and so future interoperable solutions. Emails do the same, when they start, which means when we really have a diversity/interoperability problem in communications: offer a means to develop a common ground on top instead offer a "common solution to be adopted". Every single product change, but needs tend to remain the same, Greenspun's tenth rule of programming perhaps is another example that tell the same thing better. I hope to be clear, English is not my motherlanguage and so express "philosophical" concept with it it's not easy for me...
DonHopkins 8y ago
Oh come on. Shoehorning EVERYTHING into a one dimensional array of characters is a terrible idea. That is why Bourne Shell is a piece of shit, and PowerShell rocks.
- xte 8y ago
  Windows PowerShell? That's abominable piece of managerial-driven crap? Well... It rocks, in the sense of rock falling on the genitals of it's users... Sorry for being rude but well... There are many aspects of ancient OSes that does not work well, mostly because time passes and no one really advance BUT if you want a good comparison try provisioning Windows with PS and NixOS with NixOps, after a month tell the difference.
  - DonHopkins 8y ago
    Have you ever typed "more configure" instead of "./configure"? Really? Are you seriously advocating that crap?
    - xte 8y ago
      I do not understand what you say... Yes, I use in the past GNU autotools and I see the enormous amount of text they produce, not much different by the amount of crap any RAD IDE produce alongside a project but you talking about PowerShell, an Windows IaC solution, not a software development tool to help portability. I'm respond: compare it to another GNU/Linux IaC solution, NixOS/NixOps. If you compare them you may notice: - they are both built-in in their respective OSes - they are both a language and a framework to configure/deploy/provisioning systems, local and in LAN - they have both a DSL for that Well, NixOS realize easily a semi-unbreackable OS you can easily replicate anywhere, PS realize a MONSTER that only to learn in you need weeks, and even after so you can't really replicate Windows, you can at maximum provision an already deployed Windows instance. I do not see how GNU Autotools fit in that comparison.
      - DonHopkins 8y ago
        I can't really make out what you're trying to say, either. I'm asking you if you think that file oriented shells like sh, csh or bash (or any Unix shell short of Perl, Python, Emacs or node.js) are reasonable scripting languages for plugging together software components, the way PowerShell is. For example, PowerShell lets you pass around an array of filenames, and doesn't blow up if there are spaces in the file names the way the shell does. PowerShell enables software components to export and consume rich well defined APIs that take and return actual objects and data structures, not just strings of text that you then have to parse on your own. Even though it would be extremely useful, Unix shells are absolutely terrible at parsing text and manipulating data structures, and have to call out to other weak programs like sed and awk to do even the most rudimentary parsing, pattern matching and string manipulation. Historically and until recently, Unix shells weren't even able to add two numbers: you actually had to run another program called "expr" to do that, and forking another process and parsing its string output is ASTRONOMICALLY less efficient that executing an ADD instruction. Unix shell scripting is pathetically wasteful and inefficient, and a huge pain in the ass to program, read and maintain. https://www.tutorialspoint.com/unix_commands/expr.htm https://www.tutorialspoint.com/unix_commands/expr.htm The following is an example involving boolean expressions ( |- or operator ): $ expr length "abcdef" "<" 5 "|" 15 - 4 ">" 8 output: 1 Everything is NOT a file. You shouldn't have to fork another process and parse a file to add two numbers, or put double quotes around your logical operators for that matter. Plan 9 got it dead wrong. And that's why nobody uses Plan 9, and why modern Unix isn't anything like it. I get it that you're in a reflexive tizzy about how evil and corporate everything from Microsoft automatically is in your book. But I'm afraid you simply don't know what you're talking about. Since you're not able to talk about PowerShell rationally, then what about Python or Emacs? They're real programming languages, not lame mish-mashes of haphazard syntax and inconsistent semantics like Unix shells, and they don't view everything as a one-dimensional file like Plan 9 insists. They have actual libraries with real APIs and honest to god objects and data structures, not just files. In Emacs Lisp, files actually have their own local variables, containing any Lisp objects or s-expressions. http://www.gnu.org/software/emacs/emacs-paper.html#SEC19 http://www.gnu.org/software/emacs/emacs-paper.html#SEC19 And if you really continue to insist that everything should be represented as one-dimensional file, then how to you explain ioctl and fcntl and setsockopt? The official error code returned by ioctl sums up my point about Plan 9's fatal mistake: ENOTTY: NOT A TYPEWRITER. https://en.wikipedia.org/wiki/Not_a_typewriter https://en.wikipedia.org/wiki/Not_a_typewriter

by xte 8y ago

rakoo 8y ago

Plan9 sure is a marvel of engineering because all interactions amount to reading/writing a specific file, but it doesn't solve the issue that is interoperability: it merely defines a way to connect to the remote service, but it doesn't say what the functional interface is. - what "files" should I read from or write to ? - what format should I use ? - when should I interact with said files ? Is it ok to tail -f it or should I reopen it every time I want to get some new information ? XML in itself didn't solve anything, it's the standards over how to define a grammar and validate it that made all the interoperability.

xte 8y ago
IMVHO there is a unnoticed problem underneath, probably best explained by XKcd standard's vignette (927), we will NEVER really accept for long time "proposed solution" but we can converge by nature to a common solution if we find a comfortable common way to move. Plan9 for me is an answer because yes, it does not solve problems you rightly pointed out, but instead offer a common ground to reduce them by nature. It offer a dramatically simple and effective "networked" solution so a good ground on top of which we can develop a future of IT and so future interoperable solutions. Emails do the same, when they start, which means when we really have a diversity/interoperability problem in communications: offer a means to develop a common ground on top instead offer a "common solution to be adopted". Every single product change, but needs tend to remain the same, Greenspun's tenth rule of programming perhaps is another example that tell the same thing better. I hope to be clear, English is not my motherlanguage and so express "philosophical" concept with it it's not easy for me...

DonHopkins 8y ago

Oh come on. Shoehorning EVERYTHING into a one dimensional array of characters is a terrible idea. That is why Bourne Shell is a piece of shit, and PowerShell rocks.

xte 8y ago
Windows PowerShell? That's abominable piece of managerial-driven crap? Well... It rocks, in the sense of rock falling on the genitals of it's users... Sorry for being rude but well... There are many aspects of ancient OSes that does not work well, mostly because time passes and no one really advance BUT if you want a good comparison try provisioning Windows with PS and NixOS with NixOps, after a month tell the difference.
- DonHopkins 8y ago
  Have you ever typed "more configure" instead of "./configure"? Really? Are you seriously advocating that crap?
  - xte 8y ago
    I do not understand what you say... Yes, I use in the past GNU autotools and I see the enormous amount of text they produce, not much different by the amount of crap any RAD IDE produce alongside a project but you talking about PowerShell, an Windows IaC solution, not a software development tool to help portability. I'm respond: compare it to another GNU/Linux IaC solution, NixOS/NixOps. If you compare them you may notice: - they are both built-in in their respective OSes - they are both a language and a framework to configure/deploy/provisioning systems, local and in LAN - they have both a DSL for that Well, NixOS realize easily a semi-unbreackable OS you can easily replicate anywhere, PS realize a MONSTER that only to learn in you need weeks, and even after so you can't really replicate Windows, you can at maximum provision an already deployed Windows instance. I do not see how GNU Autotools fit in that comparison.
    - DonHopkins 8y ago
      I can't really make out what you're trying to say, either. I'm asking you if you think that file oriented shells like sh, csh or bash (or any Unix shell short of Perl, Python, Emacs or node.js) are reasonable scripting languages for plugging together software components, the way PowerShell is. For example, PowerShell lets you pass around an array of filenames, and doesn't blow up if there are spaces in the file names the way the shell does. PowerShell enables software components to export and consume rich well defined APIs that take and return actual objects and data structures, not just strings of text that you then have to parse on your own. Even though it would be extremely useful, Unix shells are absolutely terrible at parsing text and manipulating data structures, and have to call out to other weak programs like sed and awk to do even the most rudimentary parsing, pattern matching and string manipulation. Historically and until recently, Unix shells weren't even able to add two numbers: you actually had to run another program called "expr" to do that, and forking another process and parsing its string output is ASTRONOMICALLY less efficient that executing an ADD instruction. Unix shell scripting is pathetically wasteful and inefficient, and a huge pain in the ass to program, read and maintain. https://www.tutorialspoint.com/unix_commands/expr.htm https://www.tutorialspoint.com/unix_commands/expr.htm The following is an example involving boolean expressions ( |- or operator ): $ expr length "abcdef" "<" 5 "|" 15 - 4 ">" 8 output: 1 Everything is NOT a file. You shouldn't have to fork another process and parse a file to add two numbers, or put double quotes around your logical operators for that matter. Plan 9 got it dead wrong. And that's why nobody uses Plan 9, and why modern Unix isn't anything like it. I get it that you're in a reflexive tizzy about how evil and corporate everything from Microsoft automatically is in your book. But I'm afraid you simply don't know what you're talking about. Since you're not able to talk about PowerShell rationally, then what about Python or Emacs? They're real programming languages, not lame mish-mashes of haphazard syntax and inconsistent semantics like Unix shells, and they don't view everything as a one-dimensional file like Plan 9 insists. They have actual libraries with real APIs and honest to god objects and data structures, not just files. In Emacs Lisp, files actually have their own local variables, containing any Lisp objects or s-expressions. http://www.gnu.org/software/emacs/emacs-paper.html#SEC19 http://www.gnu.org/software/emacs/emacs-paper.html#SEC19 And if you really continue to insist that everything should be represented as one-dimensional file, then how to you explain ioctl and fcntl and setsockopt? The official error code returned by ioctl sums up my point about Plan 9's fatal mistake: ENOTTY: NOT A TYPEWRITER. https://en.wikipedia.org/wiki/Not_a_typewriter https://en.wikipedia.org/wiki/Not_a_typewriter