1. 24
  1.  

  2. 9

    Completeness can be sacrificed in favor of any other quality. In fact, completeness must be sacrificed whenever implementation simplicity is jeopardized. Consistency can be sacrificed to achieve completeness if simplicity is retained; especially worthless is consistency of interface.

    In a way the so called “New Jersey style” was a rush for a minimum viable product able to minimize the time-to-market and to gain the first mover advantage.

    These are grim tidings indeed.

    Everyone who works in software sees broken, dysfunctional systems that just keep getting worse with time. More and more money goes into working around their deficiencies, and real fixes are rare. Everyone who works in software thinks “surely there has to be a better way” but according to Gabriel, the forces of survival-of-the-fittest say “no, there can’t be a better way. I won’t allow it.”

    We see good software in side-projects, in fun weekend hacks, and we go to work thinking “if I were in charge here, this would be like that”, but it can’t be. In a sufficiently competitive environment, “messy and now” beats “clean, but tomorrow” every time.

    1. 4

      Reading your comment I was filled with sorrow, because it feels so very right. But the more I thought on it, I realize that often “clean, but tomorrow” morphs into “clean, but next year,” if you’re not careful. And being given carte blanche to deliver whenever doesn’t work for businesses, and unless you’re a philosophic communist, we’re all in the business of something. The important part is striking the right balance between doing it well enough and delivering it on a decent timeline. That’s what you get from a high performing team, and that’s why processes like agile arose. And that’s life too: constraint balancing. Often those constraints are interpreted as bad, but that value judgement comes from us, not the constraint.

      Put another way, there is no ivory tower where everything is perfect and all solutions are fully explored.

      1. 2

        Put another way, there is no ivory tower where everything is perfect and all solutions are fully explored

        …and money is made.

      2. 2

        The environment doesn’t even need to be competitive. It just needs to involve money and people wanting what they tend to want: things done cheap.

      3. 4

        Is there a race condition between the failed system call and checking for wake up? What if the time slice expires immediately after a system call failed for a different reason?

        1. 2

          This approach feels wrong. I think a better approach would be to have all syscalls become async, including sleep, and then provide a blocking ‘wait’ syscall that waits on multiple events. From the last time I looked, this even fits nicely into the plan 9 internals.

          So, something like this:

            int rr = read(fd, buf, n);
            int tr = sleep(timeout);
            int id, r;
            r = wait((int[]){rr, tr}, &id);
            switch (id){
            case 0: /* timeout */
            case 1: /* read result */
            }
          

          This also means that you get pipelining of read requests and the ability to hide latency, and remove the need to remember checking for timeout.

          1. 1

            It also means most “calls” (except “wait”) can become messages rather than procedure invocations. Isn’t this how a microkernel is supposed to work?