1. 4

    In my Copious Free Time (read: after my kids are in college, so ~15 years from now) I’d like to port Oberon to the Raspberry Pi. It would be fun.

    1. 2

      It was one of the ideas I had for Raspberry Pi 3. I keep thinking about buying one. They say it’s best even if less hardware since so much software already works on it. Helps newcomers out. I want an always-on box that doesn’t use much power.

      Oberon port, either Oberon or A2 Bluebottle, was one of my ideas. I also thought about porting it to Rust then backporting it to Oberon. Basically, knocking out any temporal errors plus letting it run without GC. Then, Oberon-to-C-to-LLVM for performance boost. Oberon in overdrive. ;)

      If you wait 15 years on your project, then Wirth’s habits might mean there will be another 5-10 Oberon’s released with minor, feature changes before you get started. He might try dropping if statements or something. Who knows.

      1. 2

        He might try dropping if statements or something. Who knows.

        Well actually I would remove the FOR loop given it’s just syntactic sugar for a WHILE.

        However for some reason it seems that Wirth likes it. :-)

        Anyway… Wirth is a light source in these dark days: he will always remind us that less features mean less bugs.

        1. 5

          less features mean less bugs

          It can also mean more bugs in the next layer up, if the dearth of features at a particular layer requires people to constantly reimplement even basic functionality.

          1. 1

            This is exactly why I countered Wirth’s philosophy. We see it in action already where modern languages can:

            (a) improve productivity expressing solutions with better abstractions or type inference

            (b) improve performance with features like built-in parallelism and highly-optimizing compilers

            (c) improve safety/security with things like better type systems

            1. 1

              @jclulow and you propose a good objection, but I think you are confusing easyness with simplicity.

              I see the features that a language (or an operating system) supports like the dimensions that can describe a program (or a dynamic ecosystem of users interacting with hardware devices).

              Thus, to me, an high number of features (as many system calls in an OS or many forms in a programming language) are smells of a (potentially) broken design, full of redundancy and features that do not compose well.

              On the flip side, a low number of features can mean either a low expressivity (often by design, as in most domain specific languages) or a better designed set of orthogonal features. Or it might just be a quick and dirty hack whose sole goal was to solve a contingent issue in the fastest and easiest possible way.

              My favourite example to explain this concept is to compare Linux+Firefox with Plan 9 (and then Plan 9 to Jehanne, that is specifically looking for the most orthogonal set of abstractions/syscalls that a powerful distributed OS can provide).

              It’s not just a matter of code bloat, performance, security and so on, it’s a matter of power and expressivity: with few well designed features you can express all the features provided by more complex artifacts… but also a wide new set that they cannot!

              Simplicity is also an important security feature, in particular for programming languages.

              1. 1

                I get what you’re saying. Your view is actually more nuanced than Wirth’s. The main measure of complexity for Wirth was how long it took to compile the compiler. If it took a lot longer, he’d drop the feature. I think longer compiles are fine if they give us something in return. I also favor an interpreter + compiler setup for rapid development followed by high optimization. We have a lot of means to get high correctness regardless of the features in it. I’m seeing all rewards with no losses. Certainly people can put in stupid features or needless complexity which I’d be against. Wirth just set the bar way, way, too low.

                “with few well designed features you can express all the features provided by more complex artifacts…”

                Macros, modules, generics, polymorphism… a few examples.

                “Simplicity is also an important security feature, in particular for programming languages.”

                You probably shouldn’t be citing that paper given it’s one of the rarest attacks in existence. Compiler optimizations screw up security the most but people always cite Thompson. Anyway, I originally learned security reading work of the guy Thompson ripped off: Paul Karger. I wrote here about Karger’s invention of the problem and how you solve it. It’s a totally-solved problem. For new solutions, we have a page collecting tiny and verified versions of everything to help newcomers build something more quickly.

                1. 3

                  with few well designed features you can express all the features provided by more complex artifacts…

                  Macros, modules, generics, polymorphism… a few examples.

                  Exactly!

                  You do not need a compiler to generate code. You just need the compiler to verify the generated code before compilation.

                  Embedding code generation in a compiler (or a runtime, as Jit compiler do) can be convenient, but I’m not sure it’s teally needed.

                  Obviously it’s pointless to restrict yourself from using a supported language feature to pick “the good parts”. I use macros in C for example. But I also generate C in other ways when it’s appropriate and it’s pretty simple and usable. Thus I like Oberon that omit a possible source of complexity just like I like LISP and Scheme that maximise the gain/complexity ratio by raising the gain.

                  You probably shouldn’t be citing that paper given it’s one of the rarest attacks in existence.

                  I stand corrected (and thanks for these references!).

                  But the point I was trying to make was more general: we cannot trust “trust” in technology.

                  And the laymen cannot trust us either, as when they do we fool and exploit them.

                  Thus we need to rebuild the IT world from the ground up, focusing on simplicity from the very beginning. So that fellow programmers can rapidly inspect and understand everything.

                  The main measure of complexity for Wirth was how long it took to compile the compiler. […]
                  Wirth just set the bar way, way, too low.

                  He really doesn’t need my defence, but I don’t think that minimizing compiler’s compilation time is the goal, but just a metric.

                  AFAIK, the reasoning is: if it’s slow to compile (with a decent compiler), it means in could be simpler.

                  In other words, compilation time is a sort of canary that complexity kills for first.

    1. 2

      Are there any technologies that is in Oracle Solaris 11 that is not there in OpenIndiana at this point?

      1. 2

        There was time when OpenZFS did not had encryption support and Oracle Solaris ZFS had it, but now its implemented, not yet pushed into latest OpenIndiana release but its in the upstream Illumos source and it will also be available on FreeBSD, Linux, macOS and other Illumos distributions.

        Currently its quite opposite, OpenZFS version has more features then Oracle ZFS, while device removal is available at both the OpenZFS also has ability to add a driver to RAIDZ (for example from 5 drives to 6 drives) the new DRAID implementation is in the works - similar to what is available on IBM Storwize V7000 or HPE 3PAR enterprise storage arrays, also ZSTD compression will be available on OpenZFS and not on Oracle ZFS …

        1. 1

          ZFS encryption is not yet available in the illumos source, as people are still working out issues with it.

        2. 2

          Kernel Zones, immutable zones, DTrace/mdb DWARF support.

        1. 5

          the laboriousness of writing an article when my opinion could be captured in a sentence, just so i can use the term “ipso facto”

          1. 2

            And to misuse a semicolon at the same time!

            1. 1

              why i never

          1. 1

            I’m not sure I’m sold on this. I get why people building infrastructure software like redis might want this. Yes, it helps them keep the “Foo as a Service” market as a captive income stream without competition from AWS, et al. At the same time it seems like for any service of much worth, it’s going to get cloned by the big providers anyway, and then you have a proliferation of similar but incompatible closed-source versions. I’m not convinced that is necessarily good for the community at large.

            1. 2

              I think it’s just a protection to avoid a Redis as a service launched with plain redis and few bits here and there to make the offering work. Big players can obviously clone it and have theirs, but at least most small to middle size players are eliminated. (From what I understand).

              1. 3

                You can still start Redis as a Service companies. I was shocked at first because I thought this concerned Redis and their aim was to kill all of the Redis as a Service providers which already exist. But it turns out Redis Core is unaffected by this, only some modules are.

                I don’t really know what they intend to achieve with this, except having people avoid using their modules…

                1. 2

                  Which doesn’t seem worthwhile, as the big players are the ones most likely to be able to market and monetise a service based on core Redis plus their own proprietary add-ons. It’s pretty difficult to compete with AWS on any front at this stage, given their massive resources and the “nobody ever gets fired for buying X” safety of big brands.

                  Boxing out only the small players doesn’t really feel like it’s going to preserve a whole bunch of market or mindshare for the Redis company.

                  1. 1

                    I’m not into business very much, so I cannot evaluate if this operation is worth it or not, I would just assume that they were going for the long tail, which can be a sufficient number of clients to have decent revenue and continue to work on the Redis company.

                    1. 1

                      In reality I don’t have the feeling that a “long tail” actually exists for a lot of these types of services. I base this on the Firebase/Parse era when there were loads of “backend as a service” companies around that have all withered away (my understanding at least). With only google/Firebase remaining. I personally was surprised by this.

              1. 4

                Never heard of it, but it seems like a super interesting approach to interactive environment. I cannot help but remember this Bret Victor’s talk about how we have been programming in almost-anachronistic ways with no innovation in the interfaces.

                1. 8

                  There’s nothing obsolete about text. Visual languages don’t work. They’ve been tried hundreds of times, to no avail, because GUIs are fundamentally bad user interfaces for experienced users. Text is a better interface for power users, and programming languages are for power users.

                  1. 14

                    Why can’t I re-sort the definitions in my source instead of scrolling around then? Why is it hard to see a dependency graph for all my functions? Why do I have to jump between files all the time? Text - an interface for linear presentation of information - is fundamentally a kludge for code, which is anything but linear.

                    1. 1

                      Why can’t I re-sort the definitions in my source instead of scrolling around then?

                      Sort them by what? It wouldn’t be difficult to write a script using the compiler module of Python to reorder the declarations in your file in an order you chose, which you could then use to replace the text of a buffer in your text editor. But usually I’d suggest what you want is to see a list of definitions in a particular order, which you could then use to jump to the definitions.

                      In every case that I’ve seen of not using plain text, it inevitably become inscrutable. What is actually in my Smalltalk/Lisp image? What is actually there? What can people get out of it later when I deploy it?

                      Why is it hard to see a dependency graph for all my functions?

                      Because nobody has written something that will take your source files, determine their dependencies, and produce the DOT output (a very popular text-based format for graphs, far superior in my opinion to any binary graph description format) for that graph? It’s not like it’s particularly difficult.

                      Why do I have to jump between files all the time?

                      Because it turns out it’s useful to organise things into parts. Because it turns out it’s useful to be able to parallelise compilation and not reparse every bit of code you’ve ever written every time you change any part of it.


                      I think that it’s definitely a requirement of any decent programming language to have a way to easily take the source code of that programming language and reify it into a syntax tree, for example. That’s very useful to have in a standard library. In Lisp it’s just read, Python has more complex syntax and requires more machinery which is in a standard library module, other languages have similar things.

                      One point might be: maybe you don’t need a dependency graph if you can just make your code simpler, maybe you don’t need to jump around files much if your code is properly modularised (and you have a big enough screen and narrow enough maximum line length to have multiple files open at once), maybe sorting your definitions is wrong and what you want is a sortable list of declarations you can jump to the definitions.

                      Not to mention that version control is important and version controlling things that aren’t text is a problem with conventional version control tools. Might not be an issue, you have your own VCS, but then you enter the land of expecting new users of your language to not only not use their standard editor, but also to not use their standard VCS, not use their standard pastebin, etc. How do you pastebin a snippet of a visual language so someone on an IRC channel can see it and give you help? How do you ask questions on StackOverflow about a visual language?

                      It’s not even an issue of them being unusual and unsupported. By their very nature, not using text means that these languages aren’t compatible with generic tools for working with text. And never will be. That’s the thing about text, rather than having many many many binary formats and few tools, you have one binary format and many many tools.

                      1. 8

                        Hey Miles, thanks for elaborating. I think we could have more interesting discussions if you give me a bit more credit and skip the trivial objections. You’re doing the same thing you did last time with C++ compilers. Yes, I know I could write a script, it’s not the point. I’m talking about interactive tools for source code analysis and manipulation, not a one-off sort.

                        I don’t agree with your objections about parallel compilation and parsing. It seems to me that you’re just thinking about existing tools and arguing from the status quo.

                        Further down, you make a suggestion which I interpret as “better languages could mitigate these issues” which is fair, but again I have to disagree because better languages always lead to more complex software which again requires better tools, so that’s a temporary solution at best.

                        You also raise a few objections, and here I should clarify that what I have in mind is not some kind of visual flowchart editor. What I’m claiming is that the conflation of internal representation and visual representation for code is counterproductive, but I think that a display representation that mostly looks like text is fine (as long as it’s actually within a structured editor). What I’m interested in is being able to manipulate symbols and units of code as well as aspects of its structure rather than individual characters.

                        Consequently, for pastebin or StackOverflow, you could just paste some text projection of the code, no problem. When it comes to VCS, well, the current situation is quite poor, so I’d welcome better tools there. For example, if there was a VCS that showed me diffs that take into account the semantics of the language (eg like this: https://www.semanticmerge.com), that would be pretty cool.

                        For the rest of your objections, I offer this analogy: imagine that we only had ASCII pictures, and none of this incompatible JPG/PSD/PNG nonsense with few complicated tools. Then we could use generic tools for working with text to manipulate these files, and we wouldn’t be constrained in any way whether we wanted to create beautiful paintings or complex diagrams. That’s the thing about text!

                        I think the practitioners and particularly academics in our field should have more sense of possibilities and less affection for things the way they are.

                        1. 1

                          When it comes to VCS, well, the current situation is quite poor, so I’d welcome better tools there.

                          Existing VCS could work reasonably well if the serialisation/“text projection” was deterministic and ‘stable’, i.e. minimising the amount of spurious changes like re-ordering of definitions, etc. As a first approximation I can imagine an s-expression language arranging the top-level expressions into lexicographic order, spreading them out so each sub-expression gets its own line, normalising all unquoted whitespace, etc. This would be like a very opinionated gofmt.

                          If users wan’t to preserve some layout/etc. then the editor can store that as metadata in the file. I agree that semantics-aware diffing would be great though ;)

                          1. 1

                            So you always end up separating the storage format from display representation in order to create better tools, which is exactly my point.

                            1. 1

                              Yes, I agree with your points. Was just remarking that some of these improvements (e.g. VCS) are easier to prototype and experiment with than others (e.g. semantics-aware queries of custom file formats).

                          2. 1

                            The way I see it is that there are tools for turning text into an AST and you can use them to build the fancy things you want. My point wasn’t ‘you can write that sort as a one-off’. You can edit code written in a text-based programming language with a really fancy editor that immediately parses it to an AST and works with it as an AST, and only turns it into text when written to disk. I have no problem with that. But really you’re still editing text when using something like paredit.

                            Something like vim but where the text objects are ‘identifier’, ‘ast node’, ‘expression’, ‘statement’, ‘logical line of code’, ‘block’, etc. rather than ‘text between word separators’, ‘text between spaces’, ‘line’, etc. would be a useful thing. In fact, you could probably do this in vim. I have an extension I use that lets you modify quotes around things taking into account escaped quotes within, etc. That’d probably work way better if it had that default structure for normal text and then could be customised to actually take into account the proper grammar of particular programming languages for which that is supported.

                            What I’m concerned about is the idea that it’s a good idea to store code in a proprietary binary file format that’s different for every language, where you can’t use the same tools with multiple languages. And then having to reimplement the same basic functionality for every single language in separate IDEs for each, where everything works slightly differently.

                            I do find it useful that I can do ci( and vim will delete everything inside the nearest set of parentheses, properly taking into account nesting. So if I have (foo (hello 1 2 3) bar) and my cursor is on the a, it’ll delete everything, even though the nearest ( and ) are beside hello and not foo. That kind of thing, more structured editing? I’m all for that.

                            Consequently, for pastebin or StackOverflow, you could just paste some text projection of the code, no problem. When it comes to VCS, well, the current situation is quite poor, so I’d welcome better tools there. For example, if there was a VCS that showed me diffs that take into account the semantics of the language (eg like this: https://www.semanticmerge.com), that would be pretty cool.

                            Ultimately I think if you have a recognised standardised text projection of your code, you might as well just make that the standardised format for it, then your fancy editor or editor plugin can parse it into the structures it needs. This helps ensure you can edit code over SSH, and have a variety of editors compatible with it, rather than just the single language-designer-provided IDE.

                            One of the nice things about git is that it stores snapshots internally rather than diffs. So if you have a language-specific tool that can produce diffs that are better due to being informed by the grammar of the language (avoiding the problem of adding a function and the diff being ‘added a new closing brace to the previous function then writing a new function except for a closing brace’, for example), then you can do that! Change the diff algorithm.

                            For the rest of your objections, I offer this analogy: imagine that we only had ASCII pictures, and none of this incompatible JPG/PSD/PNG nonsense with few complicated tools. Then we could use generic tools for working with text to manipulate these files, and we wouldn’t be constrained in any way whether we wanted to create beautiful paintings or complex diagrams. That’s the thing about text!

                            Well I mean I do much prefer creating a graph by writing some code to emit DOT than by writing code to emit PNG. I did so just the other day in fact. http://rout.nz/nfa.svg. Thank god for graphviz, eh?

                            Note that there’s also for example farbfeld, and svg, for that matter: text-based formats for images. Just because it’s text underneath doesn’t mean it has to be rendered as ASCII art.

                            1. 1

                              Cool, I’m glad we can agree that better tools would be good to have.

                              As far as the storage format, I don’t actually have a clear preference. What’s clearly needed is a separation of storage format and visual representation. If we had that, arguments about tabs vs spaces, indent size, let/in vs where, line length, private methods first or public methods first, vertical vs horizontal space (and on and on) could be nullified because everybody could arrange things however they like. Why can’t we have even such simple conveniences? And that’s just the low hanging fruit, there are far more interesting operations and ways of looking at source that could be implemented.

                              The other day there was a link to someone’s experiment (https://github.com/forest-lang/forest-compiler) where they use one of the text projections as the storage format. That might work, but it seems to me that the way parsing currently happens, there’s a lot of unnecessary work as whole files are constantly being reparsed because there is no structure to determine the relevant scope. It seems that controlling operations on the AST and knowing which branches are affected could be a lot more efficient. I’m sure there’s plenty of literature of this - I’ll have to look for it (and maybe I’m wrong about this).

                              What I’m concerned about is the idea that it’s a good idea to store code in a proprietary binary file format that’s different for every language, where you can’t use the same tools with multiple languages. And then having to reimplement the same basic functionality for every single language in separate IDEs for each, where everything works slightly differently.

                              I understand your concern, but this sounds exactly like the current state of affairs (other than really basic stuff like syntax highlighting maybe). There’s a separate language plugin (or plugins) for every combination of editor/IDE and language, and people keep rewriting all that stuff every time a new editor becomes popular, don’t they?

                              One of the nice things about git is that it stores snapshots internally rather than diffs.

                              Sure, we can glean a bit more information from a pair of snapshots, but still not much. It’s still impossible to track a combination of “rename + change definition”, or to treat changes in the order of definitions as a no-op, for example. Whereas if we were tracking changes in a more structured way (node renamed, sub-nodes modified etc.), it seems like we could say a lot more meaningful things about the evolution of the tree.

                              Thank god for graphviz, eh?

                              Perhaps the analogy was unclear. Being able to write a set of instructions to generate an image with a piece of software has nothing to do with having identical storage format and visual representation. If we approached images the same way we approach code, we would only have ASCII images as the output format, because that’s what is directly editable with text tools. Since you see the merits of PNG and SVG, you’re agreeing that there’s merit in separating internal/storage representation from the output representation.

                              1. 1

                                What I’m concerned about is the idea that it’s a good idea to store code in a proprietary binary file format that’s different for every language

                                I might have missed something, but I didn’t see anyone proposing this.

                                In particular, my understanding of Luna is that the graphical and textual representations are actually isomorphic (i.e. one can be derived if given the other). This means we can think of the textual representation as the being both a traditional text-based programming language and as a “file format” for serialising the graphical programming language.

                                Likewise we can switch to a text view, use grep/sed/etc. as much as we like, then switch back to a graphical view if we want (assuming that the resulting text is syntactically valid).

                          3. 1

                            Tools that improve navigation within textual source have existed for a long time. I’ve been using cscope to bounce around in C and Javascript source bases for as long as I can remember. The more static structure a language has, the easier it is to build these tools without ambiguity. The text source part isn’t really an issue – indeed it enables ad hoc tooling experiments to be built with existing text management tools; e.g., grep.

                            1. 4

                              Those tools aren’t text, though. They’re other things the augment the experience over just using text which becomes an incidental form of storage. Tools might also use AST’s, objects, data flows, constraints, and so on. They might use anything from direct representation to templates to synthesis.

                              I think the parent’s point was just text by itself is far more limited than that. Each thing I mentioned is available in some programming environment with an advantage over text-driven development.

                              1. 1

                                I think it’s wrong to say that the text storage is incidental. Line-oriented text files are about the lowest common denominator way we have to store data like this.

                                For starters, it’s effectively human-readable – you can lift the hood up and look at what’s underneath, understanding the effect that each individual character has on the result. Any more complicated structure, as would be generally required to have a more machine-first structured approach to program storage, is not going to have that property; at least not to the same extent.

                                If this thread demonstrates anything, it’s that we all have (at times, starkly!) different preferences for software engineering tools. Falling back on a textual representation allows us to avoid the need to seek consensus on a standard set of tools – I can use the editor and code manipulation tools that make sense to me, and you can stick to what makes sense to you. I think a lot of the UNIX philosophy posturing ends up being revisionist bunk, but the idea that text is a pretty universal interface for data interchange isn’t completely without merit.

                                1. 6

                                  The under-the-hood representation is binary-structured electricity that gets turned into human-readable text by parsing and display code. If already parsing it and writing display code, then one might just as well use a different encoding or structure. Text certainly has advantages as one encoding of many to have available. Plugins or input modules can take care of any conversions.

                                  Text does often have tooling advantages in systems like UNIX built with it in mind, though.

                                  1. 1

                                    I think it’s a reductionist argument for the good-enough, hard earned status quo. I think it can be valid, but only within a very narrow perspective - operational and short term.

                                    To my mind, your position is equivalent to this: we should only have ASCII images, and we don’t need any of that PNG/JPG/PSD stuff with complicated specialised tools. Instead, we can use generic text tools to make CAD drawings, diagrams, paintings - whatever. All of those things can be perfectly represented in ASCII, and the text tools will not limit us in any way!

                                2. 2

                                  I want to search my code like a database, e.g. “show my where this identifier is used as a parameter to a function” - the tooling for text doesn’t support this. Structured tooling would be super useful.

                                  1. 2

                                    Many things can be “queried” with grep and regular expressions. Which is also great to find “similar occurrences” that need to be checked but are only related by some operators and function calls following another. But on the other hand I’d definitely argue that IDEs at least have a tiny representation of the current source file for navigation or something and that you can click some token and find its uses, definitions, implementations … But it only works if I disable the low power mode. And with my 8Gb RAM MacBook I sometimes have to kill the IDE before running the program to make sure I can still use it at the same time.

                                    1. 7

                                      Maybe if it wasn’t parsing and re-parsing massive amounts of text all the time, it would be more energy efficient…

                                    2. 1

                                      Exactly. And it could extend beyond search; code could be manipulated and organised in more powerful ways. We still have rudimentary support for refactoring in most IDEs, and so we keep going through files and manually making structurally similar changes one by one, for no reason other than the inadequate underlying representation used for code.

                                      I could be wrong and maybe this is impossible to implement in any kind of general way beyond the few specific examples I’ve thought of, but I find it strange that most people dismiss the very possibility of anything better despite the fact that it’s obviously difficult and inconvenient to work with textual source code.

                                      1. 1

                                        The version of cscope that I use does things of that nature. The list of queries it supports:

                                        Find this C symbol:
                                        Find this global definition:
                                        Find functions called by this function:
                                        Find functions calling this function:
                                        Find this text string:
                                        Change this text string:
                                        Find this egrep pattern:
                                        Find this file:
                                        Find files #including this file:
                                        Find assignments to this symbol:
                                        

                                        I use Find functions calling this function a lot, as well as Find assignments to this symbol. You could conceivably add more query types, and I’m certain there are other tools that are less to my admittedly terminal-heavy aesthetic preference that offer more flexible code search and analysis.

                                        The base structure of the software being textual doesn’t get in the way of this at all.

                                        1. 3

                                          Software isn’t textual. We read the text into structures. Our tools should make these structures easier to work with. We need data structures other than text as the common format.

                                          Can I take cscope’s output and filter down to “arguments where the identifiers are of even length”?

                                          1. 5

                                            Compilers and interpreters use structured representations because those representations are more practical for the purposes of compiling and interpreting. It’s not a given that structured data is the most practical form for authoring. It might be. But what the compiler/interpreter does is not evidence of that.

                                            1. 1

                                              Those representations are more practical for searching and manipulating. Try it!

                                            2. 1

                                              I would also be interested on your thoughts about Lisp where the code is already structured data. This is an interesting property of Lisp but it does not seem to make it clearly easier to use.

                                              1. 2

                                                but it does not seem to make it clearly easier to use.

                                                Sure it does: makes macros easier to write than a language not designed like that. Once macros are easy, you can extend the language to more easily express yourself. This is seen in the DSL’s of Common LISP, Rebol, and Racket. I also always mention sklogic’s tool since he DSL’s about everything with a LISP underneath for when they don’t work.

                                        2. 2

                                          Sure, but all of these tools (including IDEs) are complicated to implement, error-prone, and extremely underpowered. cscope is just a glorified grep unless I’m missing something (I haven’t used it, just looked it up). The fact that you bring it up as a good example attests to the fact that we’re still stuck somewhere near mid-twentieth century in terms of programming UI.

                                          1. 4

                                            I bring it up as a good example because I use it all the time to great effect while working on large scale software projects. It is relatively simple to understand what it does, it’s been relatively reliable in my experience, and it helps a lot in understanding the code I work on. I’ve also tried exuberant ctags on occasion, and it’s been pretty neat as well.

                                            I don’t feel stuck at all. In fact, I feel wary of people attempting to invalidate positive real world experiences with assertions that merely because something has been around for a long time that it’s not still a useful way to work.

                                      2. 2

                                        Have you noted, that the Luna language has dual representation? Where each visual program has an immediate and easily editable text representation, and the same is true in the other direction as well? This is intended to be able to keep the benefits of the text interface, while adding the benefits of a visual representation! That’s actually the main idea behind Luna.

                                        1. 1

                                          What about the power users who use things like Excel or Salesforce? These are GUIs perfectly tailored to specific tasks. A DJ working with a sound board certainly wouldn’t want a textual interface.

                                          Textual interfaces are bad, but they are generic and easy to write. It’s a lot harder to make an intuitive GUI, let alone one that works on something as complex as a programming language. Idk if Luna is worthwhile, but text isn’t the best user interface possible imho

                                          1. 3

                                            DJs use physical interfaces, and the GUIs emulation of those physical interfaces are basically all terrible.

                                            I’ve never heard of anyone liking Salesforce, I think that must be Stockholm Syndrome. Excel’s primary problem in my opinion is that it has essentially no way of seeing how data is flowing around. If something had the kind of ‘reactive’ nature of Excel while being text-based I’d much prefer that.

                                            Textual interfaces are excellent. While there are tasks that benefit from a GUI - image editing for example - in most cases GUIs are a nicer way of representing things to a new user but are bad for power users. I wouldn’t expect first year computer science students to use vim, as it’s not beginner-friendly, but it’s by far the best text editor out there in the hands of an experienced user.

                                            1. 2

                                              I wouldn’t expect first year computer science students to use vim, as it’s not beginner-friendly, but it’s by far the best text editor out there in the hands of an experienced user.

                                              I’d call myself an “experienced user” of vim. I’ve written extensions, given workshops, and even written a language autoindent plugin, which anyone who’s done it knows is like shoving nails through your eyeballs. About once a year I get fed up with the limitations of text-only programming and try to find a good visual IDE, only to switch back when I can’t find any. Just because vim is the best we currently have doesn’t mean it’s actually any good. We deserve better.

                                              (For the record, vim isn’t beginner-unfriendly because it’s text only. It’s beginner-unfriendly because it’s UI is terrible and inconsistent and the features are all undiscoverable.)

                                              1. 2

                                                Most people don’t bother to learn vimscript properly, treating it much like people treated Javascript for years: a bunch of disparate bits they’ve picked up over time, with no unifying core. But once you actually learn it, it becomes much easier to use and more consistent. The difference between expressions and commands becomes sensible instead of seeming like an inconsistency.

                                                I never get fed up with the limitations of text-only programming, because I don’t think they exist. Could you elaborate on what you are saying those limitations are?

                                                And I totally, 100% disagree with any claim that vim’s UI is bad or inconsistent. On the contrary, it’s extremely consistent. It’s not a bunch of little individual inconsistent commands, it’s motions and text objects and such. It has extensive and well-written help. Compared to any other IDE I’ve used (a lot), it’s way more consistent. Every time I use a Mac program I’m surprised at how ad-hoc the random combinations of letters for shortcuts are. And everything requires modifier keys, which are written with ridiculous indecipherable symbols instead of ‘Ctrl’ ‘Shift’ ‘Alt’ etc. Given that Mac is generally considered to be very easy to use, I don’t think typical general consensus on ease of use is very instructive.

                                        2. 3

                                          Bret Victor explains the persistence of textual languages as resistance to change, drawing an equivalence between users of textual languages now and assembly programmers who scoffed at the first higher-level programming languages. But this thread is evidence that at least some people are interested in using a language that isn’t text-based. Not everyone is fairly characterized by Bret Victor’s generalization. So then why hasn’t that alternative emerged? There are plenty of niche languages that address a minority preference with reasonable rates of adoption. With the exception of Hypercard, I can’t think of viable graphical programming language. Even Realtalk, the language that runs Dynamicland (Bret Victor’s current focus), is text-based, being a superset of Lua. I keep hearing about how text-based languages are old-fashioned and should die out, but I never hear anything insightful about why this hasn’t happened naturally. I’m not denying that there are opportunities for big innovation but “make a visual programming language” seems like an increasingly naive or simplistic approach.

                                          1. 4

                                            I think it has to do with the malleability of text. There’s a basic set of symbols and one way to arrange them (sequentially.) Almost any problem can be encoded that way. Emacs’ excellent org-mode is a testament to the virtue of malleability.

                                            Excel also has that characteristic. Many, many kind of problems can be encoded in rectangles of text with formulas. (Though I might note that having more ways to arrange things allows new kinds of errors, as evidenced by the growing cluster of Excel features for tracing dependencies & finding errors.)

                                            Graphical languages are way less malleable. The language creator decides what elements, relations, and constraints are allowed. None of them let me redefine what a rectangle represents, or what relations are allowed between them. I think that’s why these languages can be great at solving one class of problem, but a different class of problem seems to require a totally different graphical language.

                                            1. 1

                                              My suspicion is that it’s because graphical languages merge functionality and aesthetics, meaning you have to think very, VERY hard about UI/UX and graphic design. You need to be doing that from the start to have a hope of it working out.

                                          1. 4

                                            This is really interesting to get an idea of how people are taking advantage of BSD! I now have a much nicer idea of why people are going to it (and am a bit tempted myself). That feeling of having to go through ports and simply not having 1st-class support for some software seems… rough for desktop usage though

                                            1. 3
                                              1. 1

                                                I mean “someone talks to me about an application and I’m interested in trying it out on my system”?

                                                I feel like the link to the CVE database is a bit of an unwarranted snipe here. I’m not talking too much about security updates, just “someone released some software and didn’t bother to confirm BSD support so now I’m going to need to figure out which ways this software will not work”.

                                                To be honest I don’t really think that having all userland software come in via OS-maintained package managers is a great idea in the first place (do I really need OS maintainers looking after anki?). I’m fine downloading binaries off the net. Just nicer if they have out of the box support for stuff. I’m not blaming the BSDs for this (it’s more the software writer’s fault), just that it’s my impression that this becomes a bit of an issue if you try out a lot of less used software.

                                                1. 4

                                                  As an engineer that uses and works on a minority share operating system, I don’t really think it’s reasonable to expect chiefly volunteer projects to ship binaries for my platform in a way that fits well with the OS itself. It would be great if they were willing to test on our platform, even just occasionally, but I understand why they don’t.

                                                  Given this, it seems more likely to expect a good experience from binaries provided by somebody with a vested interest in quality on the OS in question – which is why we end up with a distribution model.

                                                  1. 2

                                                    Yep, this makes a lot of sense.

                                                    I’m getting more and more partial to software relying on their host language’s package manager recently. It’s pretty nice for a Python binary to basically always work so long as you got pip running properly on your system, plus you get all the nice advantages of virtual environments and the like letting you more easily set things up. The biggest issue being around some trust issues in those ecosystems.

                                                    Considering a lot of communities (not just OSes) are getting more and more involved in distribution questions, we might be getting closer to getting things to work out of the box for non-tricky cases.

                                                    1. 8

                                                      software relying on their host language’s package manager

                                                      In general I’m not a fan. They all have problems. Many (most?) of them lack a notion of disconnected operation when they cannot reach their central Internet-connected registry. There is often no complete tracking of all files installed, which makes it difficult to completely remove a package later. Some of the language runtimes make it difficult to use packages installed in non-default directory trees, which is one way you might have hoped to work around the difficulty of subsequent removal. These systems also generally conflate the build machine with the target machine (i.e., the host on which the software will run) which tends to mean you’re not just installing a binary package but needing to build the software in-situ every time you install it.

                                                      In practice, I do end up using these tools because there is often no alternative – but they do not bring me joy.

                                                      Operating system package managers (dpkg/apt, rpm/yum, pkg_add/pkgin, IPS, etc) also have their problems. In contrast, though, these package managers tend to at least have some tools to manage the set of files that were installed for a particular package and to remove (or even just verify) them later. They also generally offer some first class way to install a set of a packages from archive files obtained via means other than direct access to a central repository.

                                                      1. 3

                                                        For development I use the “central Internet-connected registry.”, for production I use DEB/RPM packages in a repository:

                                                        • forces you to limit the number of dependencies you use, otherwise too much work to package them all;
                                                        • force you to choose high quality dependencies that are easy to package or already packaged;
                                                        • makes sure every dependency is buildable from source (depending on language);
                                                        • have an “offline” copy of the dependencies, protect against “left-pad” issues;
                                                        • run unit tests of the dependencies during package build, great for QA!;
                                                        • have (PGP) signed packages that uses the distribution’s tools to verify.

                                                        There are probably more benefits that escape me at the moment :)

                                              2. 1

                                                That feeling of having to go through ports and simply not having 1st-class support for some software seems… rough for desktop usage though

                                                What kind of desktop software do you install from these non-OS sources?

                                                1. 2

                                                  Linux is moving more and more towards Flatpak and Snap for (sandboxed) application distribution.

                                                  1. 2

                                                    I remember screwing around with Flathub on the command line in Fedora 27, but right now on Fedora 28, if you enable Flatpak in the Gnome Software Center thingy, it’s actually pretty seamless - type “Signal” in the application browser, and a Flatpak install link shows up.

                                                    With this sort of UX improvements, I’m optimistic. I feel like Fedora is just going to get easier and easier to use.

                                              1. 15

                                                The management engine (and other SMM shenanigans) have been a problem for a long time, but this last year or so has been particularly depressing on account of the slew of processor-level security issues. It really feels like Intel have been letting us down on the security front for a long time, at a deeply architectural level, and it’s all catching up with us now.

                                                The operating system can only do so much to combat a CPU which is willing to hand out the keys to the castle.

                                                1. 1

                                                  Meh. Some software is definitely hot garbage, and some attitudes or schools of thought seem to encourage such results. But that’s really not representative of everything that’s happening in the field.

                                                  1. 3

                                                    Currently:

                                                    • Home office: KUL ES-87, tenkeyless, with Cherry Green MX
                                                    • Work: Unicomp Ultraclassic, the continuation of the IBM Model-M buckling spring

                                                    I use the laptop keyboard unless I know I’ll be stationary, then I drag around a KBC Poker-X with Cherry Blues.

                                                    1. 1

                                                      KUL ES-87

                                                      I have a pair of ES-87 keyboards as well – one at work and one at home – but with Cherry MX Brown switches. I like the feel, and they’re just quiet enough that I don’t get evicted from the office or my family!

                                                      I use xmodmap instead of the DIP switches on the keyboard to replace Caps Lock with Control.

                                                    1. 19

                                                      I wouldn’t feel bad about this. I don’t think it’s possible to write evergreen advice that’s actually useful that won’t also be abused by karma whoring dickheads. The alternative, no reusable advice, is much bleaker.

                                                      The dunning Kruger research was useful, and I’m glad we have it, even if it means a horde of uncomprehending jerks posts the same Wikipedia link into every thread.

                                                      1. 8

                                                        Indeed. I think the condition described in this article is alive and well today.

                                                        I try to help people with the software I work on whenever I can, because it’s the right thing to do – but the altogether too common sense of apparent entitlement and lack of basic desire to read can be draining. If anything, the chief issue with this article is that it’s too long: the people who most ought to read it will never make it to the end.

                                                      1. 10

                                                        Russ Cox wrote:

                                                        At Bell Labs, Rob switched acme and sam from black and white to color in the development version of Plan 9, called Brazil, in the late fall of 1997. I used Brazil on my laptop as my day-to-day work environment, but I was not a developer. I remember writing Rob an email saying how much I enjoyed having color but that it would be nice to have options to set the color scheme. He wrote a polite but firm response back explaining his position. He had worked with a graphic designer to choose a visually pleasing color palette. He said he believed strongly that it was important for the author of a system to get details like this right instead of defaulting on that responsibility by making every user make the choice instead. He said that if the users revolted he’d find a new set of colors, but that options wouldn’t happen.

                                                        It was really a marvelous email, polite yet firm and a crystal clear explanation of his philosophy. Over the years I have from time to time spent hours trying to find a copy of that email. It is lost.

                                                        1. 16

                                                          This is a good example of having a fundamentalist position to the point of absurdity. The idea that there will be a correct colour scheme for a text editor is an amazing mix of arrogance and over-simplification.

                                                          1. 12

                                                            And ignores the fact that not everyone has “correct” vision and color perception.

                                                            1. 2

                                                              And not every display is created equal, either. Nor every physical environment. (I switch themes when I use my laptop outdoors, because my usual low-contrast theme is illegible there.)

                                                              1. 1

                                                                That seems silly.

                                                                I go outside sometimes too, but I adjust the contrast and colour temperature of the entire system, since I do more than edit text.

                                                                1. 2

                                                                  Oh, that makes sense. When I take my old ThinkPad outside, I don’t have internet access, so, it’s highly unlikely that I will be doing anything other than editing text. :) In recent history, this has only happened when I’m a passenger on a long drive. There are a couple of toy C programs I putz around with to pass the time.

                                                            2. 2

                                                              The idea that there will be a correct colour scheme for a text editor is an amazing mix of arrogance

                                                              Why?

                                                              I have my own opinions on the matter, but it seems to me that optimising a colour scheme for a set of requirements (contrast, colour blindness, long exposure time, etc) is probably possible.

                                                              I think most people have a brand preference for a set of colours that is something else though.

                                                              and over-simplification.

                                                              The depth of the response may be lost to us, but surely it is irresponsible to assume it was done without thought given here is an accomplished programmers report that the response was in fact, quite thoughtful?

                                                              1. 2

                                                                I have my own opinions on the matter, but it seems to me that optimising a colour scheme for a set of requirements (contrast, colour blindness, long exposure time, etc) is probably possible.

                                                                There are many considerations that go into people’s selections of color schemes that intrinsically vary, including physical environments (e.g., home vs. office), time of day (e.g., daylight vs. evening light), and simple personal preference. To insist that there be no option to change the colors – on principle – is to tell everybody who might care about these considerations that they’re flat out wrong and that the author knows that before having talked with them. As if that’s not arrogant enough, it’s even more arrogant (and illogical) to further claim that even if one were wrong about the specific colors chosen, they’re still right about the broader point that there’s only one appropriate color scheme for an editor.

                                                                The bit about author’s responsibility is a red herring. I, too, believe that it’s important for authors to choose an appropriate set of configuration parameters. I also believe there’s nothing wrong with users wanting different values.

                                                                1. 1

                                                                  I think it supporting multiple physical environments (gamma/contrast) and time of day (temperature) doesn’t beg for multiple colour schemes: That’s just lazy engineering. This is obviously a job for the display manager or monitor setup.

                                                                  Being left with “simple personal preference” isn’t satisfying; People can have a “simple personal preference” about nearly everything, Flat earth, Metric system, Fish on Friday, and so on. Some editors support more preferences than others.

                                                                  In terms of something wrong with “users wanting different values”, one thing I particularly dislike about preferences is sitting down at another persons workstation and being unable to help them quickly (i.e. with minimal mental load on myself) because they have configured damn near everything that can be configured.

                                                                  1. 3

                                                                    I think it supporting multiple physical environments (gamma/contrast) and time of day (temperature) doesn’t beg for multiple colour schemes: That’s just lazy engineering. This is obviously a job for the display manager or monitor setup.

                                                                    I don’t think that’s obvious at all.

                                                                    Being left with “simple personal preference” isn’t satisfying; People can have a “simple personal preference” about nearly everything, Flat earth, Metric system, Fish on Friday, and so on.

                                                                    “Flat earth” is a scientific model, the purpose of which is to make predictions, and that model makes no useful predictions that aren’t made more accurately by other models. If you were building software that depended on a model of the earth, I think it would be fair to leave out a “flat earth” model because it’s objectively less useful. Meal choices are indeed a personal preference – and if you were building software for people to record their meals, I’d recommend against supporting only one possible food. Few people would find it reasonable to tell somebody what single food they must eat for all meals. Choice of unit system has properties of both; there are tradeoffs with different systems, and most software provides an option to switch between them.

                                                                    My main point is that to provide an option is to allow for the possibility that you might be wrong and enable users to adjust as they need to. To refuse the option (on principle) is to assert that anybody who wants it to work differently is wrong by construction.

                                                                    It seems like you’re taking the conjecture (that there is only one optimal color scheme) as an axiom and, faced with a data point like a person claiming to prefer a different color scheme, conclude that the person is irrational (akin to a flat earth believer). That seems backwards to me.

                                                                    In terms of something wrong with “users wanting different values”, one thing I particularly dislike about preferences is sitting down at another persons workstation and being unable to help them quickly (i.e. with minimal mental load on myself) because they have configured damn near everything that can be configured.

                                                                    I agree with how annoying this is, but I would not even consider to insist that people use no customizations for the tiny fraction of time I spend in their environments.

                                                                    1. 1

                                                                      It seems like you’re taking the conjecture (that there is only one optimal color scheme) as an axiom

                                                                      I’m humouring it, sure.

                                                                      Here’s a smart guy who has convinced another smart guy – the exact conversation lost, but the impression remained. I’m giving it the benefit of the doubt because that’s how we ourselves begin to be convinced of strange and unusual ideas.

                                                                      I’m still making my own opinion here:

                                                                      It seems possible to have a colour scheme optimised for certain things.

                                                                      It might not be possible to optimise for every thing, and it’s certainly not possible to optimise for everything once you’ve permitted “personal preference” to be one of those things; as an extreme example, people had personal preference not to sit next to black people on the bus – so I think it’s absolutely foolish to admit “personal preference” so quickly.

                                                                      most software provides an option to switch between them.

                                                                      Feature parity is often a useful goal, but I don’t see how it’s relevant. The feature either generally useful or specifically popular, and the argument is clearly about the former.

                                                                      That seems backwards to me.

                                                                      That’s why thinking about it is useful.

                                                                      I think you can start from either position: That choice is good or choice is bad. It’s almost certainly not that simplistic, but I see no good reason to start at the end you are starting from, and several easy reasons not to.

                                                                    2. 2

                                                                      Being left with “simple personal preference” isn’t satisfying;

                                                                      Their personal preference might be based on something like “I’m colorblind” or “I have a sensory integration disorder” or “I need a high-contrast theme because I have extremely poor vision.” Sometimes preferences are out of necessity.

                                                                      1. 1

                                                                        I don’t agree that those things are “simple personal preference”.

                                                                        I touched briefly on why, but reading back it might not be clear:

                                                                        Accessibility is actually probably something that can be optimised for – that is to say, a colour scheme can be optimised for colourblindness, contrast needs, integration disorders, and so on.

                                                                        However even if personal needs remain unaccommodated, I’m still not sure every application being written needs to reinvent the wheel to add this kind of configuration. Notwithstanding the risk/reward questions (e.g. how many people have these kinds of problems, really), it still seems like it would be smarter engineering to get your display manager/windowing environment to do it, not to mention more convenient for users.

                                                                        So: Still not convinced.

                                                            1. 6

                                                              Huh. Why do people think open offices are meant to increase interaction? The only reason for open offices is a lack of floor real estate. I’ve been stuck in them for over six years because I’ve only really taken work in cities.

                                                              Do managers actually believe the lie that it makes people more productive? I use to hate the cube, so much, but open offices are a new layer of hell.

                                                              1. 7

                                                                I think people (including managers) are, on average, pretty poor at empathising with different levels of tolerance for social interaction. If the manager finds the open office level of interaction tolerable or even enjoyable, on balance I expect they will project this onto their staff as what they perceive to be a reasonable expectation.

                                                                Not everybody is this way, but it seems quite common – not just in office layout decisions, but in weighing the cost of additional meetings or even in planning for team social events. In contrast I’ve known people that are themselves comfortable with a lower level of interaction, and their lower level tends to influence their targets for others too.

                                                                1. 8

                                                                  I have met in every open office a vocal fraction of colleagues who said they enjoyed it. “here I csn stay informed on what is going on in the department”, a small office would be isolating, et etc.

                                                                  So managers will find people who share their opinion.

                                                                  Also typically middle management doesnt decide on this stuff but more higher ups who either have their own office or spend their days in meeting rooms.

                                                              1. 2

                                                                Is upstream illumos looking into modern compiler support?

                                                                1. 6

                                                                  We are definitely on that path. In SmartOS (a downstream project in the illumos family) we’re doing some work right now to make it easier to run both gcc 4.4.X and gcc 6 (as what we call a shadow compiler) in our build process. Eventually, when we’re sure it works properly, we’ll make the transition forward.

                                                                  1. 5

                                                                    (Disclaimer: Unleashed is my creation.)

                                                                    illumos is slowly fixing up the code to get newer gcc working. There has been a lot of fixups to make gcc7/8 happy, but neither Unleashed nor illumos are close to building with a compiler newer than gcc 4.4.4. (Unleashed gets those fixups via periodic git-pulls.)

                                                                    In Unleashed, given our limited resources, we haven’t specifically targeted a compiler update yet, but we have removed support for Sun Studio (cc and lint) to simplify the transition. If anyone is interested, the “compiler update project” is up for grabs. :)

                                                                  1. 4

                                                                    “Hooray! We have forked an already small community into yet another smaller community because…”

                                                                    Well, the “because” doesn’t really matter, even though they make extremely valid points! In an already incredibly fragmented community (how many derivatives of OpenSolaris does this make?) this makes the problem bigger…

                                                                    I don’t follow illumos very closely, but are there reasons that community won’t assist in pushing towards solving the concerns that sparked unleashed? Surely illumos is also an operating system that “developers want to use,” no?

                                                                    1. 10

                                                                      As always, we’re happy to work with people who want to push changes to illumos-gate!

                                                                      1. 5

                                                                        xkcd 1095 seems relevant. :^)

                                                                        1. 1

                                                                          Yeah, maybe. :)

                                                                        2. 4

                                                                          If the illumos community were healthy I would agree with you and I wouldn’t have bothered to create this fork. Sadly, I think the illumos community has problems and the people that truly have a lot of say where the project goes either don’t see them or like the status quo.

                                                                          Two years ago when I started Unleashed, I had a dilemma: should I fork illumos or ditch it for one of the BSDs. When I realized that there were other people that were just as unhappy with the (lack of) direction illumos had, making a fork sounded like a good option. That’s how we got here.

                                                                          Now where do we go from here is an open question. It is completely possible that Unleashed will fizzle, at which point I can say that no real harm was done. The illumos community will remain as small as it was two days ago, with major contributors like Delphix bailing on illumos in favor of Linux. If Unleashed takes off and in the process kills off illumos, the overall ecosystem will be better off. There might be a person or two grumpy that they can’t run their emacs binary from 1994, but in my opinion that is a small price to pay.

                                                                          Surely illumos is also an operating system that “developers want to use,” no?

                                                                          That is the reason I considered and ultimately went with a fork instead of bailing on it. The technology in Solaris/OpenSolaris/illumos/Unleashed is great, and I didn’t want to give it up. I wanted to give up the hugely inefficient and ultimately counter-productive contribution process.

                                                                          Happy hacking!

                                                                          1. 4

                                                                            Thanks for taking the time to respond. I know my post probably came off as aggressive, and if I’m honest, it was half intended to be. I think forks are very disruptive, and wish, of course, to minimize these sorts of things when at all possible.

                                                                            When I realized that there were other people that were just as unhappy with the (lack of) direction illumos had, making a fork sounded like a good option.

                                                                            This makes total and reasonable sense. I didn’t mean to imply that you hadn’t thought this through! And appreciate that you used it as a sort of last resort.

                                                                            That is the reason I considered and ultimately went with a fork instead of bailing on it. The technology in Solaris/OpenSolaris/illumos/Unleashed is great, and I didn’t want to give it up. I wanted to give up the hugely inefficient and ultimately counter-productive contribution process.

                                                                            Thanks for doing what you’re doing, and I wish Unleashed success (and maybe either domination or an eventual merge of the communities again)!

                                                                            1. 3

                                                                              Thanks for taking the time to respond.

                                                                              No problem. I really had no choice - someone on the internet was “wrong” ;)

                                                                              I know my post probably came off as aggressive, and if I’m honest, it was half intended to be.

                                                                              The phrasing certainly made me go “urgh, not one of those…” but it sounds like we both agree that forks are disruptive, but you think that it’s a negative thing while I think it is a positive thing. A reasonable difference of opinion.

                                                                              Thanks for doing what you’re doing, and I wish Unleashed success (and maybe either domination or an eventual merge of the communities again)!

                                                                              Thanks, that’s the idea :)

                                                                              1. 2

                                                                                The phrasing certainly made me go “urgh, not one of those…”

                                                                                There’s really nothing I can offer as a legitimate excuse for that. I’m sorry.

                                                                                but you think that it’s a negative thing while I think it is a positive thing. A reasonable difference of opinion.

                                                                                The additional context you’ve provided makes me feel that it probably is the right, and positive choice in this case. I’m not vehemently against forks if there’s a legitimately good reason [and just to be clear, moving on from supporting legacy stuff is the important divergence I’m seeing, as it frees up resources to move faster]. I am against forks that don’t offer some radical divergence in philosophy, though. These are often rooted from deep bikeshedding on topics that don’t matter in the grand scheme of things.

                                                                                Two examples of justified forks in my opinion: @rain1 recently forked filezilla because it was incorporating “unwanted extra nonfree software.” Devuan is a fork of Debian that replaces systemd – a topic that is far beyond bikeshedding at this point, as it’s had (and will continue to have) a drastic effect on the portability of software to other ecosystems.

                                                                                1. 1

                                                                                  There’s really nothing I can offer as a legitimate excuse for that. I’m sorry.

                                                                                  No worries. Hopefully my initial response didn’t come across as too harsh either. If it did, my apologies.

                                                                                  I am against forks that don’t offer some radical divergence in philosophy, though.

                                                                                  Agreed. Although sometimes it is hard to tell if there is a justification for the fork.

                                                                                  1. 2

                                                                                    I am against forks that don’t offer some radical divergence in philosophy, though.

                                                                                    Agreed. Although sometimes it is hard to tell if there is a justification for the fork

                                                                                    I wonder when we started to need a justification.

                                                                                    Why?

                                                                                    1. 11

                                                                                      I wonder when we started to need a justification.

                                                                                      You do you, man. You do you.

                                                                                      In my mind, there are two types of forks we’re talking about. One of them is a “fork” on github, where I clone the repo, make some changes, contribute it back to the original author (or maybe not!), and live a happy life. These types of forks are almost always ok. It’s the “You do you, man. You do you.” response.

                                                                                      The other “fork” is far more challenging, and far more likely to cause a rift in spacetime. Those are the large, and by all accounts, successful projects that as a result divide a community, and make it difficult for users and would be contributors to find the right thing to use. These projects fork very publicly, and are rather uncomfortable, to be honest.

                                                                                      In many cases, these forks occurred because egos were hurt (I wanted it yellow) – a social issue – not a technical issue. In other cases, there’s a large philosophical difference that impacts the general direction of the technology. This may be licensing, whether or not to support obscure platforms, a radical new idea or focus… etc. In all cases, even if there are legitimately great outcomes (OpenBSD comes to mind), there’s a period of confusion and frustration from users who are now forced to choose where to put their effort. They are forced into taking sides, and that’s unfair.

                                                                                      1. 1

                                                                                        These are marketing concerns. Market share issues, to be precise.

                                                                                        They are valid for open source projects that are basically marketing tools, but they are pointless for free software that maximizes hackers’ freedom to hack.

                                                                                        Feeling the need to justify a fork, is the first step towards asking permission.
                                                                                        The PATENTS file in projects like Fuchsia’s kernel sources just push for that.

                                                                                        1. 5

                                                                                          Sorry, my friend. Most people don’t share your principles on what a ‘hack,’ or a ‘hacker’ is. More often than not, the people using, and writing software care more about getting the job done quickly, and without frustration, and a fork makes that harder. It doesn’t matter how you classify it.

                                                                                          1. 0

                                                                                            people using, and writing software care more about getting the job done quickly, and without frustration

                                                                                            And this is fine!

                                                                                            But, my friend, you need to understand the tools you use!
                                                                                            If you pick up a free software that is distributed “WITHOUT ANY WARRANTY” just because it’s free of charge, and you completely miss the culture of the people who develop it, you won’t get your job done. Same if you pick an open source software controlled by Google (or whoever) and you fork it to successfully challenge their market share.

                                                                                            In both cases, you’ll face surprises, unexpected costs and frustration.

                                                                                            Understanding the environment you operate in, is strategic to “get the job done”.

                                                                                            Most people don’t share your principles on what a ‘hack,’ or a ‘hacker’ is.

                                                                                            Interesting! Do you have world-wide statistics to prove such claim?

                                                                                            Not that it matters: “principles” stand to “artifacts” like “postulates” stand to “theorems”. How many people accept the postulates/principles is irrelevant.

                                                                                            I know that some people don’t share my principles. And I’m fine with it.
                                                                                            Do you know that some people don’t share your principles?
                                                                                            Are you fine with it?

                                                                                            1. 2

                                                                                              But, my friend, you need to understand the tools you use! If you pick up a free software that is distributed “WITHOUT ANY WARRANTY” just because it’s free of charge, and you completely miss the culture of the people who develop it, you won’t get your job done. Same if you pick an open source software controlled by Google (or whoever) and you fork it to successfully challenge their market share.

                                                                                              In both cases, you’ll face surprises, unexpected costs and frustration

                                                                                              I read this several times and can’t figure out what you’re saying.

                                                                                              Why do I need to understand the culture of a tool I use? As long as it fulfills my technical needs and I know what I’m prohibited to do by law, I can use it to get my job done.

                                                                                              1. 1

                                                                                                Why do I need to understand the culture of a tool I use?

                                                                                                Some example of the issues you might face:

                                                                                                • an security update could be delayed
                                                                                                • an update upstream could break your work in production
                                                                                                • you (or one of your customers) could be sued for patent violation (even if you are not actually violating it)
                                                                                                • the project might contain backdoors and your image could be associated with it

                                                                                                and so on…

                                                                                                You could ignore the culture of tools you get for free, and be lucky.
                                                                                                But in my job, I would call that short-sight and unprofessional.

                                                                                                Software is not like an hammer: even if you take it free of charges, there are strings attached.

                                                                                                1. 2

                                                                                                  Some example of the issues you might face…

                                                                                                  There are ways around much of these concerns. I have a support contract, or trust in a distribution (say, Canonical for Ubuntu or Red Hat), which provides vuln disclosures, and updates for me to apply. I have a development process that includes QA, and automated CI infrastructure so that breaking changes are caught before production… etc.

                                                                                                  But, to the meta point:

                                                                                                  But, my friend, you need to understand the tools you use!

                                                                                                  Demonstrably this is not at all true. It’s easy to do a survey of 100 people – 10 people even, and ask them if they understand their tools. How are their tools implemented? How does the relational database they store and query data into/from store data on disk? How does the map type work in their favorite language? How does the VM work? How does the ORM work? How does the templating language they use work? How does the image processing library they use work to resize images, or rotate images, or whatever work? How does TensorFlow do all it does?

                                                                                                  What you’ll find is that a large portion of engineers have no idea how things work. And they don’t need to know. Their job is to build CRUD apps for people who could care less if something takes a little bit longer. The developer themselves, in many cases, could care less about BTREE indexes vs. HASH indexes, and doesn’t really know the difference. For the amount of data they manipulate, doing full table scans 3 times an hour (because they literally have 3 queries an hour) is completely sane, reasonable, and still puts a smile on the face of the Administrative assistant who no longer has to go to a type writer to type out a bunch of labels. Or, who no longer has to print 10,000 college applications to give to admissions reviewers… or any number of other tasks where even the worst technology choices, recommended by underskilled developers can make a ginormous (and) positive difference on the process.

                                                                                                  1. 0

                                                                                                    There are ways around much of these concerns.

                                                                                                    Sure, but the simplest one is to understand the tools you use.

                                                                                                    And actually, trusting Debian (or OpenBSD or whatever) or signing support a contract with Canonical (or Red Hat or Microsoft or whatever) requires the cultural understanding of such people I was talking about.

                                                                                                    Demonstrably this is not at all true. […]
                                                                                                    …even the worst technology choices, recommended by underskilled developers can make a ginormous (and) positive difference on the process.

                                                                                                    Practically you are saying: “everyone can become rich without working: just win the lottery!”. Well, this is not false. Stick on boring low-hanging fruits all your life and you will never face the issues that a professional developer has to consider every day.

                                                                                                    What you describe is not to “get the job done”.
                                                                                                    People die because of people who work this way.

                                                                                                    In Italy we use to say: “even a broken clock can be right twice a day”.
                                                                                                    Yes, incompetent developers can occasionally improve the life of someone, but for most of time, they just mess up things beyond repair.

                                                                                                    1. 4

                                                                                                      Practically you are saying: “everyone can become rich without working: just win the lottery!”. Well, this is not false. Stick on boring low-hanging fruits all your life and you will never face the issues that a professional developer has to consider every day.

                                                                                                      What you describe is not to “get the job done”. People die because of people who work this way.

                                                                                                      I believe this comment really lacks perspective. What you are saying is the Shamar-style of development is the only correct style of development and anyone not doing it that way is not only doing it wrong but putting people’s lives at risk.

                                                                                                      The industry I work in produces a lot of software and consumes a lot of software, however no company in this industry would consider itself a tech company. We have people whose job title is “Software Engineer”. But, for the most part, they make pretty bad technical decisions and are fairly unskilled relative to the engineers at most tech companies. But, they aren’t “trying to get rich without working” or “win the lottery”. They are very hard working. The industry just has a different set of values where the software is incidental to the actual problem the company is solving. A lot of the things you brought up in an earlier post about why one needs to understand the culture of the software they consume doesn’t actually apply in the industry I’m in. Security updates and backdoors are almost never going to be a concern because these systems are not open to the outside. The data they consume is entirely generated and processed inside the walls of the company. In the industry I’m in, we’re actually saving lives too! I mean that literally.

                                                                                                      I hate to use this word, but your comment is elitist. Anyone not solving problems how you say is not a professional and just causing damage “beyond repair”. Your comment lacks humility and perspective yet is extremely assertive. It might be worth stepping back and questioning if what you assert so strongly is an ideal, a belief, or reality. Or perhaps it’s a challenge with the language and you don’t realize how assertive your comments sound relative to how assertive you meant them to be. But insisting people not following your development principles are killing people is a pretty strong statement, in any case.

                                                                                                      1. 0

                                                                                                        But insisting people not following your development principles are killing people is a pretty strong statement, in any case.

                                                                                                        I was not talking about software development in particular.

                                                                                                        Incompetent engineers build bridges that fell off.
                                                                                                        Incompetent phyisicians do not cure mortal deseases properly. And so on.
                                                                                                        They can get some work done, but it’s lucky, like winning te lottery.

                                                                                                        As for software, I do not means that a competent software developer cannot adopt a cheap half-working solution instead of an expensive “right” one (whatever it means in the context).

                                                                                                        On the contrary!
                                                                                                        I mean that to make a choice you need competence.

                                                                                                        I’m saying that only a competent professional that knows the tools she use can really “get the job done”.
                                                                                                        An incompetent one can be lucky some times, but you cannot trust her products and thus the job is not done.

                                                                                                        Or perhaps it’s a challenge with the language

                                                                                                        Actually, I’m rather surprised by the opposition such a simple and obvious concept is facing. All other craftmen I know (the real ones, not the software ones) agree that it takes years to “own” their tools.

                                                                                                        Probably we have diverged too much from the original topic, and we are facing a deep cultural mismatch.

                                                                                                        In Europe (that, let me say, is not living up to its own values these days) we are used to be very diverse and inclusive (note: it took centuries of wars, rapes, debates, commerce, poetry, science, curiosity and many other contaminations to get here).

                                                                                                        But we do not meld the meaning of words just to include more people.

                                                                                                        We clearly see and state the differences, and happily talk about them.

                                                                                                        And this is not elitism, it’s efficient communication.

                                                                                                        When we say “job” or “done” we convey a precise message.
                                                                                                        And if a bridge fell off and kills someone, we call the engineers who built it liars because the job was not done. At times they even stop being called engineers at all.

                                                                                                        1. 2

                                                                                                          You don’t give an inch, do you? I’ve explicitly said that I work in an industry that does not do software development like you have expressed it should be done and your response is to keep on insisting on it. On top of that, you did this annoying thing where this discussion has clearly been about software development but when I pushed back you move the goal post and start talking about bridges and medicine. It’s extremely challenging and frustrating to communicate with you, I need to work on not doing that. Thanks for the discussion, it was insightful for myself.

                                                                                                      2. 3

                                                                                                        Looks like someone got a degree in being right on the Internet! There’s no point in engaging with you, and if there was a feature to block users, I would make use of it.

                                                                                                        1. 0

                                                                                                          I’m sorry about this.

                                                                                                          If you lack arguments to support your assuptions, I can suggest to simply state such assumptions clearly. For example:

                                                                                                          Users and companies are entitled to get work and value from software developers for free, because they are in a rush to get their job done.
                                                                                                          FS and OSS forks hurts this right.

                                                                                                          I would deeply disagree on such premise.
                                                                                                          But I wouldn’t argue against the conclusions.

                                                                                                          1. 2

                                                                                                            Did you just tell me to go fuck myself?

                                                                                                            1. 1

                                                                                                              Ok, this must really be a language problem.

                                                                                                              I cannot find a translation of what I wrote that can be interpreted that way!

                                                                                                              Anyway: No, I’m not telling you to fuck yourself.

                                                                                                              1. 2

                                                                                                                I just spent 30 minutes carefully crafting a response to your absurd notion that everyone must be highly skilled or people will die. But, it’s just not worth it. You’ll find a way to twist it into something it’s not, and yell loudly about how I’m wrong without considering that you may be shortsighted in your assumptions.

                                                                                                                1. 0

                                                                                                                  I’m sorry for the time you wasted.

                                                                                                                  I do not think that “everyone must be highly skilled or people will die”.

                                                                                                                  I think that everyone should be professional in his own job.
                                                                                                                  Which, at the bare minimium, means to understand the tools you use.

                                                                                                                  you may be shortsighted in your assumptions.

                                                                                                                  I woudn’t even engage if I woud not assume this to be possible: there would be nothing to learn.

                                                                              2. 3

                                                                                Question that I have that isn’t clear from the post. Do you intend to maintain enough compat with Illumos that you would be able to get improvements that were done n something like SmartOS? Are you planning on continuing to pulls changes from Illumos? Planning to try contributing changes back? Or is this a hard fork where you don’t imagine there would be cross pollination?

                                                                                1. 4

                                                                                  Good questions!

                                                                                  1. Source-level compat, yes until it stops to make sense. Binary compat, no.
                                                                                  2. I’ll continue git-pull from illumos-gate until it starts to be too cumbersome due to divergence. Once that happens, I’ll probably still take commits from illumos-gate but I’ll be more selective. In addition to illumos-gate, we cherry-pick changes from the illumos downstreams (omnios, illumos-joyent, etc.). This is open source, if those repos have good changes I’d be stupid not to take them because they were authored “outside”.
                                                                                  3. I have no plan to get changes back into illumos, however the code is open so others can do it. As an example, Toomas Soome took one of the cleanups in Unleashed and got it into illumos-gate (87bdc12930bfa66277c45510e399f8a01e06c376). He also has a work-in-progress to get our cpio-based boot_archives into illumos, but I don’t know the status of that.

                                                                                  Hopefully I covered everything.

                                                                            1. 4

                                                                              What exactly is a “hosted” operating system?

                                                                              1. 2

                                                                                A rose by any other name would be known as a runtime platform or environment. See also Erlang/OTP.

                                                                                A hosted operating system punts on all the distracting/interesting/useful parts of OS stuff in order to focus on the aesthetic of the programming environment.

                                                                                1. 6

                                                                                  A hosted operating system punts on all the distracting/interesting/useful parts of OS stuff in order to focus on the aesthetic of the programming environment.

                                                                                  This might an appropriate description of a virtual machine.

                                                                                  Inferno is a distributed operating system.

                                                                                  It’s rather different from a mainframe OS, such as Windows or Linux: all services of a network are served to the user with a uniform interface and programs can be distributed over the network transparently, moving data or computations as required.

                                                                                  The network as a whole is your computing device.

                                                                                  Now, once you understand this, you might wonder if it’s really so important who write the drivers for a single node.
                                                                                  Turns out it doesn’t matter that much: as long as the interface is uniform the system works as a whole.

                                                                                  Now I agree that an OS running on top of an OS is weird. Much more an OS running on top of a browser!

                                                                                  But sadly, it’s what your cloud vps do. And what any OS that target WASM want to do.

                                                                                  Guess what? Inferno did both things several years ago!
                                                                                  And better, with an uniform interface.

                                                                                  Try this on your mainframe of choice! ;-)

                                                                                  1. 2

                                                                                    I’m not sure what you mean by mainframe OS, though it seems like it’s an attempt at derision?

                                                                                    Virtual machines like those you might rent from a cloud provider are much more a partitioning technology these days. Though there is another operating system running on the same hardware (in the “hypervisor” role), the guest operating system is also interacting directly with quite a lot of CPU management, and increasingly other hardware devices via passthrough mechanisms. Critically, that same software can also run outside the emulation/hypervisor environment: it can take control of an entire computer, providing services to other software, and is thus an operating system.

                                                                                    In the case of software that isn’t able to (or perhaps even intended to) run on a computer directly without other scaffolding, it’s really not an operating system. If it’s really a network service or programming environment built to run on top of other things (“hosted”, if you will!) it would be less confusing to call it that. There’s obviously no shame in building an amazing new platform for constructing distributed applications – it’d just be best to avoid hijacking existing terminology while doing so.

                                                                                    1. 2

                                                                                      I’m not sure what you mean by mainframe OS, though it seems like it’s an attempt at derision?

                                                                                      Absolutely no!

                                                                                      I was trying to distingush the OSes that are designed for a single computer (thus in the ancient and noble tradiction of mainframes) from the OSes that are designed for a network of eterogenous computers.

                                                                                      When we talk about distributed operating systems, the focus is not in the control of the hardware of a single pc, but in the control of a whole network.

                                                                                      In the case of Inferno, you can run it on bare metal, on Windows, on Linux, on Plan9, on some game platforms and on IE8 (if I remember correctly).

                                                                                      This covers a variety of architectures that few mainstream OS could compete with.
                                                                                      Without an hardware emulator.

                                                                                      it’d just be best to avoid hijacking existing terminology while doing so

                                                                                      I’m afraid Inferno was defined as a distributed operating system before “existing terminology” was conceived.

                                                                                      So one might argue that existing terminology was designed by people either ignoring previous art or meaning something different.

                                                                                      In both cases, I will keep calling Inferno an OS.

                                                                                      1. 2

                                                                                        I’m afraid Inferno was defined as a distributed operating system before “existing terminology” was conceived.

                                                                                        I don’t think that’s true at all. Even the Wikipedia page for Inferno suggests it was released in 1996, and links to at least one paper from the authors from around that time. I think we’d kind of settled on an operating system being a body of software chiefly responsible for controlling an actual machine and providing services to software and users by then.

                                                                                        By way of contrast, the Amoeba distributed operating system is another attempt (and seemingly prior to Inferno!) that is both distributed (providing network transparency as a core system primitive) and an operating system (Amoeba includes a microkernel base which runs on all of the machines throughout a deployment). Sprite is another similar project, also late 1980s to early 1990s, in which some level of network transparency was achieved in addition to the base job of an operating system: controlling the machine.

                                                                                        1. 1

                                                                                          I’m not sure if this count as an objection. :-)

                                                                                          Fine, Amoeba and Sprite are distributed operating systems.
                                                                                          Plan 9 is a distributed operating system too. So is Inferno, that can run on bare metal AND hosted by another OS.

                                                                                    2. 1

                                                                                      You mean different from a centralized mainframe. The CTOS system looks pretty close to a distributed OS. Customers were loving it, too.

                                                                                      Far as OS on an OS, IBM invented that (I think…) in VM/370 in the 1970’s. VM could even run itself mainly for debugging. Mainframes also supported multiple users and metered CPU/memory. The cloud reinvents mainframes on cheaper hardware with more flexible software. The core concepts were a mainframe advantage, though.

                                                                                    3. 2

                                                                                      Right, it definitely doesn’t feel like an especially appropriate use of the term until it’s also in control of the actual machine. If it’s a runtime environment and library, it seems clearer to just call it that.

                                                                                      1. 1

                                                                                        The point at which services are provided to programs by “the operating system” versus other programs present but not considered part of the “operating system” is blurry, and getting blurrier all the time in a distributed world. “Control of the actual machine” sounds like the definition of a kernel, which can certainly be part of an operating system, but isn’t the whole thing.

                                                                                        tl;dr: what you’re referring to as Linux is actually GNU/Linux,,,

                                                                                        1. 2

                                                                                          Not all of the control of the machine is in the hands of the kernel in every operating system. For instance, in illumos we perform some amount of interrupt configuration from a privileged process running in usermode (intrd(1M)) – but it’s still part of the operating system.

                                                                                          Words have a meaning, and I think eroding the term operating system does us a terrible disservice. There are already loads of other terms that better describe a program that runs on top of an operating system and provides services to other programs, whether over local IPC mechanisms or through some network protocol.

                                                                                          It’s true that a distribution of Linux may include quite a lot of software that isn’t really “operating system” software per se; e.g., chat clients or drawing software. But if your software doesn’t have the ability to take a computer from cold start up to running some other workload, it’s really not, itself, an operating system.

                                                                                          1. 2

                                                                                            I think eroding the term operating system does us a terrible disservice.

                                                                                            I’m totally for a precise and clear technical language!

                                                                                            But, why we write hardware emulators like qemu, xen, virtual box and so on… if we cannot run operating systems on them?

                                                                                            And if what run on qemu is an operating system when it provides the user all the tools she needs, why a software that does the same but run without the hardware emulator is that different?

                                                                                    4. 1

                                                                                      Because they mention Inferno on the description they probably mean that in addition to running on ‘bare metal’ it can also run in an emulator inside another OS. Same as Inferno.

                                                                                      1. 1

                                                                                        no, but their approach to not doing so is quite entertaining.

                                                                                      1. 18

                                                                                        I no longer believe that daemons should fork into the background. Most Unix systems now have better service control and it makes the code easier to deal with if it doesn’t call fork(). This makes it easier to test (no longer do you have to provide an option not to fork() or an option to fork()) and less code is always better.

                                                                                        1. 6

                                                                                          Not forking also allows logging to be an external concern and the process should just write to stdout and stderr as normal.

                                                                                          1. 1

                                                                                            This is not so much about the forking per se, but rather the other behaviour that generally goes with it: closing any file descriptors that might be connected to a controlling terminal.

                                                                                          2. 4

                                                                                            OpenBSD’s rc system seems to expect that processes fork. I don’t see an obvious workaround for processes that don’t fork.

                                                                                            1. 3

                                                                                              It’s not that hard to write a program to do the daemonization (call umask(), setsid(), chdir(), set up any redirection of stdin, stdout and stderr, then exec() the non-forking daemon.

                                                                                              1. 2

                                                                                                It’s even simpler when you have daemon(3): http://man7.org/linux/man-pages/man3/daemon.3.html

                                                                                                1. 1

                                                                                                  Which you do on OpenBSD, actually.

                                                                                                  Note that daemon(3) is a non-standard extension so it should be avoided for portable code. The implementation is simple enough, though.

                                                                                              2. 2

                                                                                                I’m not sure this is accurate, at least on -current. There are several go “deamons” that as far as I understand don’t support fork(2). These can still be managed by OpenBSD’s rc system:

                                                                                                # cd /etc/rc.d
                                                                                                # cat grafana                                                                                                                                                                                                  
                                                                                                #!/bin/ksh
                                                                                                #
                                                                                                # $OpenBSD: grafana.rc,v 1.2 2018/01/11 19:27:10 rpe Exp $
                                                                                                
                                                                                                daemon="/usr/local/bin/grafana-server"
                                                                                                daemon_user="_grafana"
                                                                                                daemon_flags="-homepath /usr/local/share/grafana -config /etc/grafana/config.ini"
                                                                                                
                                                                                                . /etc/rc.d/rc.subr
                                                                                                
                                                                                                rc_bg=YES
                                                                                                rc_reload=NO
                                                                                                
                                                                                                rc_cmd $1
                                                                                                

                                                                                                I’m not sure if there’s more to it that I don’t understand, I don’t write many deamons!

                                                                                                1. 1

                                                                                                  Well, it turns out, I can’t read! The key to this is rc_bg, see https://man.openbsd.org/rc.subr#ENVIRONMENT

                                                                                              3. 1

                                                                                                For those that don’t know, daemontools is a nice service system that explicitly wants programs to not try to daemonize themselves. For services I build and run I try to use that.

                                                                                              1. 36

                                                                                                Then again, I’ve rarely seen anyone use their editor of choice well. I’ve lost count of how many times I’ve watched someone open a file in vim, realise it’s not the one they want, close vim, open another file, close it again… aaarrrgh.

                                                                                                I do this a lot, because I prefer browsing files in the shell. I make pretty extensive use of a lot of other vim features though. When did you become the arbiter of how “well” I’m using my computer?

                                                                                                1. 3

                                                                                                  Closing vim seems odd to me. Why wouldn’t one instead open the new file without closing vim? Maybe it’s a cultural thing? I don’t think anyone would do that in Emacs.

                                                                                                  1. 26

                                                                                                    “Why would I ever leave my editor” definitely feels like a common refrain from the Emacs crowd.

                                                                                                    1. 1

                                                                                                      I do the thing you quoted as well, but that is because vim is often my editor of convenience on a machine rather than my editor of choice, which is true for many usages I see of vim.

                                                                                                    2. 21

                                                                                                      Because the shell lets me change directories, list files with globs, run find, has better tab-completion (bash, anyway), etc, etc. I might not remember the exact name of the file, etc. Finding files in the shell is something I do all day, so I’m fast at it. Best tool for the job and all that.

                                                                                                      (Yes I can do all that with ! in vi/vim/whatever, but there’s a cognitive burden since that’s not how I “normally” run those commands. Rather than do it, mess it up because I forgot ! in front or whatever, do it again, etc, I can just do it how I know it’ll work the first time.)

                                                                                                      1. 6

                                                                                                        This is exactly why I struggle with editors like Emacs. My workflow is definitely oriented around the shell. The editor is just another tool among many. I want to use it just like I use all my other tools. I can’t get on with the Emacs workflow, where the editor is some special place that stays open. I open and close my editor many, many times every day. To my mind, keeping your editor open is the strange thing!

                                                                                                        1. 3

                                                                                                          It’s rather simple actually: the relationship between the editor and the shell is turned on it’s head – from within the editor you open a shell (eg. eshell, ansi-term, shell, …) and use it for as long as you need it, just like a one would use vi from a shell. Ninja-slices.

                                                                                                          You can compare this as someone who claims to log out of their x session every time they close a terminal or a shell in a multiplexer. Would seem wierd too.

                                                                                                          1. 3

                                                                                                            I know you can launch a shell from within your editor. I just never really understood why you would want to do that.

                                                                                                            Obviously some people do like to do that. My point is just that different ways of using a computer make intuitive sense to different people. I don’t think you can justify calling one way wrong just because it seems odd to you.

                                                                                                            1. 6

                                                                                                              I know you can launch a shell from within your editor. I just never really understood why you would want to do that.

                                                                                                              I do it because it allows me to use my editor’s features to:

                                                                                                              a) edit commands b) manipulate the output of commands in another buffer (and/or use shell pipelines to prep the output buffer) c) not have to context switch to a different window, shutdown the editor, suspend the editor, or otherwise change how I interact with the currently focused window.

                                                                                                              1. 1

                                                                                                                That makes a lot of sense. I guess I have been misleading in using the word “shell” when I should really have said “terminal emulator”. I often fire off shell commands from within my editor, for just the same reasons as you, but I don’t run an interactive shell. I like M-! but I don’t like eshell, does that make sense?

                                                                                                                Having pondered this all a bit more, I think it comes down to what you consider to be a place. I’m pretty certain I read about places versus tools here on lobsters but I can’t find it now. These are probably tendencies rather than absolutes, but I think there are at least a couple of different ways of thinking about interaction with a computer. Some people think of applications as places: you start up a number of applications, they persist for the length of your computing session, and you switch between them for different tasks (maybe a text editor, a web browser and an e-mail client, or something). Alternatively, applications are just tools that you pick up and drop as you need them. For me, a terminal, i.e. an interactive shell session, is a place. It is the only long-lived application on my desktop, everything else is ephemeral: I start it to accomplish some task then immediately kill it.

                                                                                                          2. 3

                                                                                                            It’s really simple in emacs. Just Ctrl-z and run fg when you are ready to go back.

                                                                                                      1. 1

                                                                                                        Privileged Command Execution History

                                                                                                        A new command, admhist, was included in Solaris 11.4 to show successful system administration related commands which are likely to have modified the system state, in human readable form. This is similar to the shell builtin “history”.

                                                                                                        That’s a curious one. It’s a shame the solaris manpages don’t appear to be public. I wonder if they’re logging the use of system() or exec*() in their libc.

                                                                                                        What’s worse is I immediately started thinking about how this workaround could be useful. Naughty Hales! Fix the shell configs on the servers instead. Stop imagining libc level hacks to see what coworkers have been up to.

                                                                                                        1. 4

                                                                                                          I have no idea how it’s implemented, but I would note that Solaris and illumos systems have an auditing system with kernel involvement that can capture, amongst other things, all command execution. Perhaps this is a set of filters for displaying information gathered by the existing auditing mechanism.

                                                                                                        1. 7

                                                                                                          Am I crazy? I thought Oracle killed off Solaris? Or did they just lay off a bunch of folks?

                                                                                                          1. 8

                                                                                                            They definitely sacked a lot of people, which presumably did nothing for the morale of the folks left behind either. We picked up some of the people jumping ship at Joyent when it happened.

                                                                                                            You can only fire or terrorise so many of the people in an organisation who know how something works before there won’t be a critical mass left to maintain it. Because of the long pipeline of work that was already underway at the time of the event (including the most recent line of SPARC microprocessors) they had a lot of stuff they could release just after the firing – “See, of course we’re not dead!” – but I wouldn’t hold out much hope for anything else.

                                                                                                            1. 1

                                                                                                              Oracle killed OpenSolaris, not Solaris.