smarks

This is too bad. The sweet spot was "hard,intr" at least when I was last using NFS on a daily basis (mid 1990s). Hard mounts make sense for programs, which will happily wait indefinitely while blocked in I/O. This worked well for things like doing a build over NFS, which would hang if the server crashed and then pick right up right where it left off when the server rebooted.

Of course this is irritating if you're blocked waiting for something incidental, like your shell doing a search of PATH. In those cases you could just control-C and continue doing what you wanted to do (as long as it didn't actually need that NFS server).

However I can see that it would be difficult to implement interruptibility in various layers of the kernel.

OK, I read the Olaf Kirch article, and the "NFS Sucks" title is mostly clickbait. There are indeed a bunch of shortcomings in NFS that he points out, that are partially addressed by NFSv4. He also admits that (as of 2006) there isn't anything better.

Locking has historically always been a problem in NFS. Kirch mentions that NLM was designed for Posix semantics only. I frankly don't know if NLM is related to `rpc.lockd` which appeared in SunOS 4 and possibly even SunOS 3 (mid 1980s at this point) which well predates anything having to do with Posix. Part of the problem is the confused state of file locking in the Unix world, even for local files. There was BSD-style `flock` and SYSV-style `lockf` and there might even have been multiple versions of those. Implementing these in a distributed system would have been terribly complex. Even at Sun, at least through the mid 1990s, the conventional wisdom was to avoid file locking. If you really needed something that supported distributed updates, it was better to use a purpose-built network protocol.

One thing "willy" got right in his comment is that NFS is an example of "worse is better". In its early version, it had the benefit of being relatively simple, as acknowledged in the LWN article. This made it easy to port and reimplement and thus it became widespread.

Of course being simple means there are lots of tradeoffs and shortcomings. To address these you need to make things more complex, and now things are "ridiculous" and "bloated". Oh well.

“Why NFS Sucks” (2006), picking on a protocol that was over 20 years old at that point. Also cites “The Unix-Haters Handbook” in the abstract. Two strikes against its credibility already.

However, I did skim the paper, and it seems halfway reasonable, so I suppose I should read the whole thing. Of course nothing is above criticism, and there are many valid criticisms of NFS; but leading with “sucks” is just lazy.

Of course, the first commenter "willy" repeats the canard that statelessness makes no sense:

> The very notion of a stateless filesystem is ridiculous. Filesystems exist to store state.

It's the protocol that's stateless, not the filesystem. I thought the article made a reasonable attempt to explain that.

Overall the article is reasonable but it omits one of the big issues with NFSv2, which is synchronous writes. Those Sun NFS implementations were based on Sun's RPC system; the server was required not to reply until the write had been committed to stable storage. There was a mount option to disable this, but if you enabled it, it exposed you to data corruption. Certain vendors (SGI, if I recall correctly) at some point claimed their NFS was faster than Sun's, but it implemented asynchronous writes. This resulted in the expected arguments over protocol compliance and reliability vs. performance.

This phenomenon led to various hardware "NFS accelerator" solutions that put an NVRAM write cache in front of the disk in order to speed up synchronous writes. I believe Legato and the still-existing NetApp were based on such technology. Eventually the synchronous writes issue was resolved, possibly by NFSv3, though the details escape me.

Several folks have pointed out the poor style in calling static methods using an instance. I think you have a good point, but not a good example. Perhaps a better example is with overload resolution. Consider this Kotlin code:

    fun foo(i: Int) = ...

    fun foo(n: Number) = ...

    fun main() {
        val n: Number = 12;
        foo(n); // calls foo(Number)
        if (n is Int) {
            foo(n); // calls foo(Int)
        }
    }

It's as if smart casting causes the static type of `n` to change in different parts of the main function. As such it also seems to affect overload resolution. Maybe this is exactly what you want. On the other hand it seems like it could lead to some very subtle errors. I'm not a Kotlin programmer, so Kotlin experts please feel free to correct me on details.

Yes, if javac is given the `-Xlint:static` option.

WING ATTACK, PLAN R

Wow, that is amazing! What portion of your investment was returned? You don't have to say the actual amounts if you don't want, but I'm curious about whether you got 1/10, 1/2, or all of your investment back.

The author is onto something but I’m afraid it’s not explained very well. I think he’s mostly right though.

While reading it I was reminded of a design/implementation style I’ve run across several times over the years which is to find an existing class that does something similar to what you want. Then, subclass it and override methods until you get the behavior you want. And you’re done!

This leads directly to the Fragile Base Class problem. I think it also violates the Open/Closed principle. When subclassing occurs across components that are released independently (e.g., a library and an application), it either leads to continual breakage at each release, or ossification of the library. The latter happened to Java’s Swing. It got to the point where it was difficult to fix any bugs, because any “fix” would end up breaking some subclass that relied on the old behavior.

(See also Hyrum’s Law, which is more general than subclassing & inheritance.)

That's very sad. Like many others, I used `cdrecord` and `mkisofs` back in the day.

But mainly I remember him for his work on SCCS. That code was AT&T proprietary for a long time, but it was open-sourced as part of OpenSolaris. Schilling made it portable and produced binaries for several platforms, including the Mac. He even gave some conference talks on this topic. By the time he did that work, most projects had already moved onto other version control systems. But there are older, closed-source histories of various projects (such as Java) that are still in SCCS, and I find his tools useful to this day for investigating those histories.

Condolences to his family.

If you have a bunch of related records you can make them public and nested within a top-level public class. You could also throw some static utility or factory methods in there too.

Yeah, that's the one that I've heard referred to as the Barfing Boy.

The “Tin Man”? Is that the same as the Barfing Boy?

La Costeña is now further down Middlefield in the shopping center at Whisman. They’re no longer a grocery store, more like a regular taqueria. They still make decent burritos and similar food.

Yes, this is sad. I remember integrating Cairo into a project I worked on a number of years ago.

At the time, pulling in an open source project was a big ordeal. You had to figure out how to build it, getting all the configuration options correct, pulling in all the dependencies, configuring them, etc. I set aside a whole afternoon to get it working.

Anyway, I pulled it down, built it, and was writing simple drawing programs in about 15 minutes. It was amazing.

Yep. I didn't believe those messages when they first came out, but over time they've mostly been proven true.

Oh excellent, I can now reread those massive threads on comp.arch about how NOTHING WILL WITHSTAND THE ATTACK OF THE KILLER MICROS!

For example:

https://www.usenetarchives.com/view.php?id=comp.arch&g=14965...

Indeed, Marohn (the author of TFA) has been attacked by other members of the civil engineering profession for his criticisms of it (going against established "dogma" as he puts it).

https://www.strongtowns.org/journal/2019/3/18/what-happens-w...

Your characterization of Loom is, I think, pretty accurate.

There are, however, a few things in Java's early concurrency support that make various things harder, including Loom, and we're having to put some extra effort into grappling with them.

Probably the most obvious is the fact that the language and VM requires every object to have a monitor lock that can be synchronized and waited/notified. In 1996 this was viewed as "Ooooh, sophisticated, building locking and concurrency support into the platform!" In recent years this has started to get in the way. Really only a very few objects are used as locks, but the _potential_ for every object to be locked is paid by the JVM.

It also intrudes on Project Valhalla, which is trying to define "identity-less" inline types (formerly, "value types"). Ideally, we'd want all conventional objects and inline objects to be descendants of java.lang.Object. But Object has the locking APIs defined on it, and locking is intertwined with object identity. So, does Object have identity or not? There are some solutions, but they're kind of weird and special-cased.

Another issue is that the locks defined by the language/VM ("synchronized") are implemented differently from locks implemented by the library (in java.util.concurrent.locks). Loom supports virtual threads taking library-based locks, in that when a virtual thread blocks on a lock it will be dismounted from the real thread. This can't be done with language/VM locks, so there's an effort underway to migrate the those locks to delegate to library code for their implementation. This isn't an insurmountable problem, but it's yet more work to be done, and it's a consequence of some of the original designs of Java 1.0's concurrency model.

I thought this was a silly joke at first, but it's actually sort-of an attempt to capture actual organizational anti-patterns. I mean at some level assigning an "immaturity level" is silly. However, characterizing various pathologies of bad organizations is helpful.

I think I've actually worked in organizations that were at level -3. Sometimes this was a reasonable goal taken to an absurd extreme. For example, a reasonable Software Quality Engineering organization's goal would be to find as many bugs as possible in the software product, or in short, to try to "break" the product. Taken to an extreme, the ability of an SQE organization to exaggerate any concern about quality to such an extent that it manages to stop the shipment of the product because of quality concerns, can be construed as a success for that SQE organization. In the case I'm thinking of, the SQE org was basically obstructionist, because they got rewarded for that. It was amazing that we managed ever to ship anything.

Yes, records work with generics pretty much the same way they work with classes. You can do

    public record MktOrder<T>(T currency, int amount) { }
    var m1 = new MktOrder<USD>(usd, amount);

Mutation without concurrency is still a problem for pattern matching. To return to your earlier example, suppose you've matched Point(3, y) and you're now in some code that assumes that the x-value of the Point is 3. Now, you call some method that has some reference to the point you're working on, and it mutates the x-value to 4. The assumption in that code after the match is now broken.

My first corporate credit card (for travel expenses) was a Diners Club. This as in 1986. It was terrible. No place would take it. I had to put all my expenses on my own credit card. Fortunately my credit limit wasn’t an issue, but having a corporate credit card that nobody will take kind of defeats the purpose of having a corporate credit card. We switched to American Express the next year.

This might have something to do with the way that name resolution worked inside of Sun at the time. If there was a host, say

    doppio.eng.sun.com

it would be referred to simply as "doppio" from within the engineering ("eng.sun.com") domain, or possibly as "doppio.eng" from other domains inside of Sun. It was fairly rare to use FQDNs inside of Sun to refer to other hosts inside of Sun. Thus, the following URLs all referred to the same resource:

    http://doppio/foo.html
    http://doppio.eng/foo.html
    http://doppio.eng.sun.com/foo.html

It's a plausible point of view that URL.equals() should report true for any two of the above URLs. (That doesn't mean that I think it was a good idea, though.)

> The post misleads readers into thinking that JVM runs the GC before exit. It does not.

Yes, the article is incorrect about this. We’ll make sure it gets fixed.

These numbers are quite interesting. Thanks for doing this analysis!

The initial concept was "value types" and we wanted a project name that was evocative of "value". Place names (even for mythical places) are good names since they cannot be trademarked. Hence, "value" => "val" => "Valhalla".

Scott McNealy was a protegé of Jack Welch, and Scott applied the Six Sigma philosophy to Sun. There was a whole corporate effort to get people trained up as black belts, etc. During the mid-2000s when the company was struggling, it was quite telling that the first people laid off from any organization were the Six Sigma Black Belts.

Is the unit a “Levadownski” which is perhaps a deliberate corruption of his name?

No. “Centum” means one hundred. Of course, the SI prefix “centi-” does mean one hundredth, but “cent-“ can mean one hundred in other contexts. Consider a century is 100 years, a centurion commands 100 men, etc.