8 ms·

“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 again

by smarks 4y ago

“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.

chasil 4y ago
If you think that was bad, just listen to what Theo de Raadt had to say. "NFSv4 is a gigantic joke on everyone....NFSv4 is not on our roadmap. It is a ridiculous bloated protocol which they keep adding crap to. In about a decade the people who actually start auditing it are going to see all the mistakes that it hides. "The design process followed by the NFSv4 team members matches the methodology taken by the IPV6 people. (As in, once a mistake is made, and 4 people are running the test code, it is a fact on the ground and cannot be changed again.) The result is an unrefined piece of trash." https://blog.fosketts.net/2015/02/03/vsphere-6-nfs-41-finally/ https://blog.fosketts.net/2015/02/03/vsphere-6-nfs-41-finall...
- smarks 4y ago
  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.
  - Enderboi 4y ago
    The funny thing is that we're running our large NFS servers on OmniOS (with Linux NFS clients), as plugins for a certain large PHP-based blogging platform loves to sprinkle LOCK_EX flocks all over the place. Sadly with a Linux NFS server, lock state eventually corrupts itself to extinction but OmniOS can tick along past 300 days uptime without a problem. Of course.... these issues only show up under production levels of load, and have never been able to be distilled into a reproducable test case. FML, and FNL ( = fricking NFS locking :P)
- wahern 4y ago
  Trash or not, the demand for the features is there. OpenBSD enjoys the luxury of simply telling people who need more sophisticated features to piss-off, at least until the time a protocol or interface has been hashed out and settled into a static target. Notably, OpenBSD has an IPv6 and IPSec (including IKE) stack second to none. If OpenBSD developers actually had a need for the features provided by NFSv4, I'm sure OpenBSD would have an exceptionally polished and refined--at least along the dimensions they care about--implementation. But they don't. What they do have is a relatively well-maintained NFSv3 and YP stacks (not even NIS!), because those things are important to Theo, especially for (AFAIU) maintaining the build farm and related project infrastructure.
  - bgm1975 4y ago
    Yp is NIS. It was renamed by Sun due to the trademark on Yellow Pages. Maybe you’re thinking of NIS+ (which was an abomination). TBH, they are both horrible for their own reasons.
    - wahern 4y ago
      Ah, yes, NIS+. Thank you for the correction. I also had in mind that OpenBSD deliberately and rigorously only refers to "YP" ("Yellow Pee"). Google "OpenBSD" and "NIS" and most of the hits you'll see directly from the OpenBSD project are from commit logs for patches removing accidental usages of "NIS" in initial YP-related feature commits. I'm not quite sure why they do that. I've kind of assumed it's to make clear that they have little interest in addressing vendor compatibility issues, and to emphasize that YP support, such as it is, is narrowly tailored to supporting the needs of the OpenBSD project itself. That's quite different from IPv6, IPSec/IKE, and even NFSv3, where cross-vendor interoperability is a concern (within reason).
      - DonHopkins 4y ago
        Speaking of YP (which I always thought sounded like a brand of moist baby poop towelettes), BSD, wildcard groups, SunRPC, and Sun's ingenuous networking and security and remote procedure call infrastructure, who remembers Jordan Hubbard's infamous rwall incident on March 31, 1987? https://news.ycombinator.com/item?id=25156006 https://news.ycombinator.com/item?id=25156006 https://en.wikipedia.org/wiki/Jordan_Hubbard#rwall_incident https://en.wikipedia.org/wiki/Jordan_Hubbard#rwall_incident >rwall incident >On March 31, 1987 Hubbard executed an rwall command expecting it to send a message to every machine on the network at University of California, Berkeley, where he headed the Distributed Unix Group. The command instead began broadcasting Hubbard's message to every machine on the internet and was stopped after Hubbard realised the message was being broadcast remotely after he received complaints from people at Purdue University and University of Texas. Even though the command was terminated, it resulted in Hubbard receiving 743 messages and complaints, including one from the Inspector General of ARPAnet. I was logged in on my Sun workstation "tumtum" when it happened, so I received his rwall too, and immediately sent him a humorous email with the subject of "flame flame flame" which I've lost in the intervening 35 years, but I still have a copy of his quick reply: From: Jordan K. Hubbard <jkh%violet.Berkeley.EDU@berkeley.edu> Date: Tue, Mar 31, 1987, 11:02 PM To: Don Hopkins <don@tumtum.cs.umd.edu> Subject: re: flame flame flame Thanks, you were nicer than most.. Here's the stock letter I've been sending back to people: Thank you, thank you.. Now if I can only figure out why a lowly machine in a basement somewhere can send broadcast messages to the entire world. Doesn't seem *right* somehow. Yours for an annoying network. Jordan P.S. I was actually experimenting to see exactly now bad a crock RPC was. I'm beginning to get an idea. I look forward to your flame. Jordan Here's the explanation he sent to hackers_guild, and some replies from old net boys like Milo Medin (who said the program manager of the Arpanet in the Information Science and Technology Office of DARPA Dennis G. Perry said they would kick UCB off the Arpanet if it ever happened again), Mark Crispin (who presciently proposed cash rewards for discovering and disclosing security bugs), and Dennis G. Perry himself: From: Jordan K. Hubbard <jkh%violet.Berkeley.EDU@berkeley.edu> Date: April 2, 1987 Subject: My Broadcast By now, many of you have heard of (or seen) the broadcast message I sent to the net two days ago. I have since received 743 messages and have replied to every one (either with a form letter, or more personally when questions were asked). The intention behind this effort was to show that I wasn't interested in doing what I did maliciously or in hiding out afterwards and avoiding the repercussions. One of the people who received my message was Dennis Perry, the Inspector General of the ARPAnet (in the Pentagon), and he wasn't exactly pleased. (I hear his Interleaf windows got scribbled on) So now everyone is asking: "Who is this Jordan Hubbard, and why is he on my screen??" I will attempt to explain. I head a small group here at Berkeley called the "Distributed Unix Group". What that essentially means is that I come up with Unix distribution software for workstations on campus. Part of this job entails seeing where some of the novice administrators we're creating will hang themselves, and hopefully prevent them from doing so. Yesterday, I finally got around to looking at the "broadcast" group in /etc/netgroup which was set to "(,,)". It was obvious that this was set up for rwall to use, so I read the documentation on "netgroup" and "rwall". A section of the netgroup man page said: ... Any of three fields can be empty, in which case it signifies a wild card. Thus universal (,,) defines a group to which everyone belongs. Field names that ... ... Now "everyone" here is pretty ambiguous. Reading a bit further down, one sees discussion on yellow-pages domains and might be led to believe that "everyone" was everyone in your domain. I know that rwall uses point-to-point RPC connections, so I didn't feel that this was what they meant, just that it seemed to be the implication. Reading the rwall man page turned up nothing about "broadcasts". It doesn't even specify the communications method used. One might infer that rwall did indeed use actual broadcast packets. Failing to find anything that might suggest that rwall would do anything nasty beyond the bounds of the current domain (or at least up to the IMP), I tried it. I knew that rwall takes awhile to do its stuff, so I left it running and went back to my office. I assumed that anyone who got my message would let me know.. Boy, was I right about that! After the first few mail messages arrived from Purdue and Utexas, I begin to understand what was really going on and killed the rwall. I mean, how often do you expect to run something on your machine and have people from Wisconsin start getting the results of it on their screens? All of this has raised some interesting points and problems. 1. Rwall will walk through your entire hosts file and blare at anyone and everyone if you use the (,,) wildcard group. Whether this is a bug or a feature, I don't know. 2. Since rwall is an RPC service, and RPC doesn't seem to give a damn who you are as long as you're root (which is trivial to be, on a work- station), I have to wonder what other RPC services are open holes. We've managed to do some interesting, unauthorized, things with the YP service here at Berkeley, I wonder what the implications of this are. 3. Having a group called "broadcast" in your netgroup file (which is how it comes from sun) is just begging for some novice admin (or operator with root) to use it in the mistaken belief that he/she is getting to all the users. I am really surprised (as are many others) that this has taken this long to happen. 4. Killing rwall is not going to solve the problem. Any fool can write rwall, and just about any fool can get root priviledge on a Sun workstation. It seems that the place to fix the problem is on the receiving ends. The only other alternative would be to tighten up all the IMP gateways to forward packets only from "trusted" hosts. I don't like that at all, from a standpoint of reduced convenience and productivity. Also, since many places are adding hosts at a phenominal rate (ourselves especially), it would be hard to keep such a database up to date. Many perfectly well- behaved people would suffer for the potential sins of a few. I certainly don't intend to do this again, but I'm very curious as to what will happen as a result. A lot of people got wall'd, and I would think that they would be annoyed that their machine would let someone from the opposite side of the continent do such a thing! Jordan Hubbard jkh@violet.berkeley.edu (ucbvax!jkh) Computer Facilities & Communications. U.C. Berkeley From: Milo S. Medin <medin@orion.arpa> Date: Apr 6, 1987, 5:06 AM Actually, Dennis Perry is the head of DARPA/IPTO, not a pencil pusher in the IG's office. IPTO is the part of DARPA that deals with all CS issues (including funding for ARPANET, BSD, MACH, SDINET, etc...). Calling him part of the IG's office on the TCP/IP list probably didn't win you any favors. Coincidentally I was at a meeting at the Pentagon last Thursday that Dennis was at, along with Mike Corrigan (the man at DoD/OSD responsible for all of DDN), and a couple other such types discussing Internet management issues, when your little incident came up. Dennis was absolutely livid, and I recall him saying something about shutting off UCB's PSN ports if this happened again. There were also reports about the DCA management types really putting on the heat about turning on Mailbridge filtering now and not after the buttergates are deployed. I don't know if Mike St. Johns and company can hold them off much longer. Sigh... Mike Corrigan mentioned that this was the sort of thing that gets networks shut off. You really pissed off the wrong people with this move! Dennis also called up some VP at SUN and demanded this hole be patched in the next release. People generally pay attention to such people. Milo From: Mark Crispin <MRC%PANDA@sumex-aim.stanford.edu> Date: Mon, Apr 6, 1987, 10:15 AM Dan - I'm afraid you (and I, and any of the other old-timers who care about security) are banging your head against a brick wall. The philsophy behind Unix largely seems quite reminiscent of the old ITS philsophy of "security through obscurity;" we must entrust our systems and data to a open-ended set of youthful hackers (the current term is "gurus") who have mastered the arcane knowledge. The problem is further exacerbated by the multitude of slimy vendors who sell Unix boxes without sources and without an efficient means of dealing with security problems as they develop. I don't see any relief, however. There are a lot of politics involved here. Some individuals would rather muzzle knowledge of Unix security problems and their fixes than see them fixed. I feel it is *criminal* to have this attitude on the DDN, since our national security in wartime might ultimately depend upon it. If there is such a breach, those individuals will be better off if the Russians win the war, because if not there will be a Court of Inquiry to answer... It may be necessary to take matters into our own hands, as you did once before. I am seriously considering offering a cash reward for the first discoverer of a Unix security bug, provided that the bug is thoroughly documented (with both cause and fix). There would be a sliding cash scale based on how devastating the bug is and how many vendors' systems it affects. My intention would be to propagate the knowledge as widely as possible with the express intension of getting these bugs FIXED everywhere. Knowledge is power, and it properly belongs in the hands of system administrators and system programmers. It should NOT be the exclusive province of "gurus" who have a vested interest in keeping such details secret. -- Mark -- PS: Crispin's definition of a "somewhat secure operating system": A "somewhat secure operating system" is one that, given an intelligent system management that does not commit a blunder that compromises security, would withstand an attack by one of its architects for at least an hour. Crispin's definition of a "moderately secure operating system": a "moderately secure operating system" is one that would withstand an attack by one of its architects for at least an hour even if the management of the system are total idiots who make every mistake in the book. ------- From: Dennis G. Perry <PERRY@vax.darpa.mil> Date: Apr 6, 1987, 3:19 PM Jordan, you are right in your assumptions that people will get annoyed that what happened was allowed to happen. By the way, I am the program manager of the Arpanet in the Information Science and Technology Office of DARPA, located in Roslin (Arlington), not the Pentagon. I would like suggestions as to what you, or anyone else, think should be done to prevent such occurances in the furture. There are many drastic choices one could make. Is there a reasonable one? Perhaps some one from Sun could volunteer what there action will be in light of this revelation. I certainly hope that the community can come up with a good solution, because I know that when the problem gets solved from the top the solutions will reflect their concerns. Think about this situation and I think you will all agree that this is a serious problem that could cripple the Arpanet and anyother net that lets things like this happen without control. dennis ------- Also: http://catless.ncl.ac.uk/Risks/4.73.html#subj10.1 http://catless.ncl.ac.uk/Risks/4.73.html#subj10.1 https://everything2.com/title/Jordan+K.+Hubbard https://everything2.com/title/Jordan+K.+Hubbard
DonHopkins 4y ago
Stewart, I think "sucks" is a pretty fair description of a protocol that actually trusted the client to tell the server what its host name is, before the server checked that the host name appears in /etc/exports, without verifying the client's ip address. On a system that makes /etc/exports easily publicly readable via tftp by default. Did you find my criticism of how X-Windows sucks in the Unix Haters Handbook as unfair and un-credible and lazy as you found the book's criticism of NFS? Or my criticism of OLWM and XBugTool, which also both sucked? https://web.archive.org/web/20000423081727/http://www.art.net/~hopkins/Don/unix-haters/x-windows/disaster.html https://web.archive.org/web/20000423081727/http://www.art.ne... Did you ever fix those high priority OLWM bugs I reported with XBugTool that OLWM unnecessarily grabbed the X11/NeWS server all the time and caused the input queue to lock up so you couldn't do anything for minutes at a time? And that related bug caused by the same grab problem that the window system would freeze if you pressed the Help key while resizing a window? Or manage to get OLWM's showcase Open Look menus to pin up without disappearing for an instant then reappearing in a different place, with a totally different looking frame around it, and completely different mouse tracking behavior? That unnecessary song and dance completely ruined the "pinned menu" user experience and pinned menu metaphor's illusion that it was the same menu before and after pinning. While TNT menus simply worked and looked perfectly and instantly when you pinned them, because it WAS the same menu after you pinned it, so it didn't have to flicker and change size and location and how it looked and behaved. Ironically, the NeWS Toolkit was MUCH better at managing X11 windows than the OLWM X11 window manager ever was, because our NeWS based X11 window manager "OWM" was deeply customizable and had a lot more advanced features like multiple rooms, scrolling virtual desktops, tabbed windows supporting draggable tabs on all four edges, resize edges, custom resize rubber banding animation, and pie menus, as well. It also never grabbed and froze the window server, and it took a hell of a lot less time and resources to develop than OLWM, which never lifted a finger to support TNT the way TNT bent over backwards to support X11. NeWS Tab Window Demo -- Demo of the Pie Menu Tab Window Manager for The NeWS Toolkit 2.0. Developed and demonstrated by Don Hopkins: https://www.youtube.com/watch?v=tMcmQk-q0k4 https://www.youtube.com/watch?v=tMcmQk-q0k4 https://web.archive.org/web/19981203002306/http://www.art.net/~hopkins/Don/unix-haters/x-windows/i39l.html https://web.archive.org/web/19981203002306/http://www.art.ne... >I39L window management complicates pinned menus enormously. TNT menus pin correctly, so that when you push the pin in, the menu window simply stays up on the screen, just like you'd expect. This is not the case with XView or even OLWM. Under an I39L window manager, the Open Look pinned menu metaphor completely breaks down. When you pin an X menu, it dissappears from the screen for an instant, then comes back at a different place, at a different size, with a different look and feel. If you're not running just the right window manager, pinned menus don't even have pins! There is no need for such "ICCCM compliant" behavior with TNT menus. When they're pinned, they can just stay there and manage themselves. But were TNT windows managed by an external I39L window manager, they would have to degenerate to the level of X menus. https://web.archive.org/web/20000602215640/http://www.art.net/~hopkins/Don/unix-haters/x-windows/xbugtool.html https://web.archive.org/web/20000602215640/http://www.art.ne... >I could go on and on, but I just lost my wonderful xbugtool, because I was having too much fun way too fast with those zany scrolling lists, so elmer the bug server freaked out and went off to la-la land, causing xbugtool to lock the windows and start "channeling", at the same time not responding to any events, so when I clicked on the scrolling list, the entire window system froze up and I had to wait for the input queue lock to break, but by the time the lock finally broke (it must have been a kryptonite), xbugtool had made up its mind, decided to meet its maker, finished core dumping, and exited with an astoundingly graceful thrash, which was a totally "dwim" thing for it to do at the time, if you think about it with the right attitude, since I had forgotten what I wanted to file a bug against in the first place anyway, and totally given up the idea of ever using bugtool to file a bug against itself, because bugtool must be perfect to have performed so splendidly! From the news-makers archive: >From: Skip Montanaro <crdgw1!montnaro@uunet.uu.net> Date: Feb 16, 1990 >Charles Hedrick writes concerning XNeWS problems. I have a couple of comments on the XNeWS situation. >The olwm/pswm interface appears (unfortunately) to be stable as far as Sun is concerned. During XNeWS beta testing I complained about the lack of function key support, but was told it was an OpenLook design issue. (NeWS1.1 supported function keys, and you could do it in PostScript if you like.) Sun likes to tout how OpenLook is standard, and was designed by human factors types. As far as I'm concerned, nobody has had enough experience with good user interfaces to sit down and write a (horribly large, hard-to-read) spec from which a window manager with a "good" look-and-feel will be created. I'm convinced you still have to experiment with most user interfaces to get them right. >As a simple example, consider Don Hopkins' recent tabframes posting. An extra goody added in tabframes is the edge-stretch thingies in the window borders. You can now stretch one edge easily, without inadvertently stretching the other edge connected to your corner-stretch thingie. Why did the OpenLook designers never think of this? SunView had that basic capability, albeit without visible window gadgetry. It wasn't like the idea was completely unheard of. >I agree that running the XNeWS server with an alternate window manager is a viable option. Before I got my SPARCStation I used XNeWS in X11ONLY mode with gwm, which was the only ICCCM-compliant window manager I had available to me at the time. If you choose to use twm with XNeWS, I recommend you at least try the X11R4 version. >From: William McSorland - Sun UK - Tech Support <will@willy.uk> Date: May 14, 1991 Subject: 1059370: Please evaluate >Bug Id: 1059370 Category: x11news Subcategory: olwm Bug/Rfe: rfe Synopsis: OLWM does a Server Grab while the root menu is being displayed. Keywords: select, frame_busy, presses, left, mouse, server, grabbed Severity: 5 Priority: 5 Description: >Customer inisisted on having this logged as a RFE and so:- >When bringing up the root menu inside OW2.0 the window manager does a Server Grab hence forcing all its client applications output to be queued by the server, but not displayed. >The customer recommends that this should be changed to make olwm more friendly. >Apparently a number of other window managers don't do a server grab while the root menu is being displayed. >From: Don Hopkins <hopkins@sun.com> Subject: 1059974: Bug report created >Bug Id: 1059974 Category: x11news Subcategory: server Bug/Rfe: bug Synopsis: I have no mouse motion and my input focus is stuck in xbugtool!!! Keywords: I have no mouth and I must scream [Harlan Ellison] Severity: 1 Priority: 1 Description: >This is my worst nightmare! None of my TNT or XView applications are getting any mouse motion events, just clicks. And my input focus is stuck in xbugtool, of all places!!! When I click in cmdtool, it gets sucked back into xbugtool when I release the button! And I'm not using click-to-type! I can make selections from menus (tnt, olwm, and xview) if I click them up instead of dragging, but nobody's receiving any mouse motion! >I just started up a fresh server, ran two jets and a cmdtool, fired up a bugtool from one of the jets (so input focus must have been working then), and after xbugtool had throbbed and grunted around for a while and finally put up its big dumb busy window, I first noticed something was wrong when I could not drag windows around! >Lucky thing my input focus ended up stuck in xbugtool! >The scrollbar does not warp my cursor either... I can switch the input focus to any of xbugtool's windows, but I can't ... -- oomph errrgh aaaaahhh! There, yes! >Aaaaah! What a relief! It stopped! I can move my mouse again!! Hurray!!! It started working when I opened a "jet" window, found I could type into it, so I moved the mouse around, the cursor disappeared, I typed, there were a couple of beeps, I still couldn't find the cursor, so I hit the "Open" key, the jet closed to an icon, and I could type to xbugtool again! And lo and behold now I can type into the cmdtool, too! Just by moving my cursor into it! What a technological wonder! Now I can start filing bug reports against cmdtool, which was the only reason I had the damn thing on my screen in the first place!!! I am amazed at the way the window system seems to read my mind and predict my every move, seeming to carry out elaborate practical jokes to prevent me from filing bugs against it. I had no idea the Open Windows desktop had such sophisticated and well integrated interclient communication! >From: Don Hopkins <hopkins@sun.com> Subject: 1059976: Bug report created Date: May 21, 1991 >Bug Id: 1059976 Category: x11news Subcategory: olwm Bug/Rfe: bug Synopsis: OLWM menus are inconsistant with the rest of the desktop, Keywords: pinned menus, defaults, tracking, inconsistant look and feel, yet another open look toolkit Severity: 2 Priority: 2 Description: >You can't set the default of a pinned menu by holding down the control key and clicking over an item. >Pressing the middle button over the default of a pinned menu erases the default ring. >You can't set the default of a unpinned menu by pressing the control key then the popping it up by pressing the MENU button on the mouse. >When you're tracking a menu, and press the control key, the highlighting changes properly, from depressed to undepressed with a default ring, but when you release the control key before releasing the MENU button on the mouse, the highlighting does not change back to depressed without a default ring. Instead it stays the same, then changes to un-depressed without a default ring at the next mouse movement, and you have to move out and back into the menu item to see it depressed again. >When you're dragging over a menu, then press the control key to set the default, then release the mouse button to make a selection, without releasing the control key, OLWM menus are stuck in default-setting mode, until the next time it sees a control key up transition while it is tracking a menu. >Clicking the SELECT button on the abbreviated menu button on the upper left corner of the window frame (aka the close box or shine mark) should select the frame menu default, instead of always closing the window. >The tracking when you press and release the control key over a menu pin is strange, as well. Push-pins as menu defaults are a dubious concept, and the HIT people should be consulted for an explaination or a correction. >When you press the menu button in a submenu, it does not set the default of the menu that popped up the submenu, the way XView and TNT menus do. This behaviour also needs clarification from the HIT team. >Pinned OLWM menus do not track the same way as unpinned menus. When you press down over an item, and drag to another item, the highlighting does not follow the mouse, instead the original item stays highlighted. The item un-highlights when the mouse exits it, but the menu highlighting should track the item underneath the cursor when the user is holding the mouse button down, just like they do with a non-pinned menu. The current behavior misleads you that the item would be selected if the button were released even though the cursor is not over the menu item, and is very annoying when you press down over a pinned menu item and miss the one you want, and expect to be able to simply drag over to the one you meant to hit. >If we are crippling our menus this way on purpose, because we are afraid Apple is going to sue us, then Apple Computer has already done damage to Sun Microsystems without even paying their lawyers to go to court. We licensed the technology directly from Xerox, and we should not make our users suffer with an inferior interface because we are afraid of boogey-men. >In general, OLWM is yet another OpenLook toolkit, and its menus are unlike any other menus on the desktop. This is a pity because the user interacts so closely with OLWM, and the conspicuous inconsistancy between the window manager and the Open Look applications that it frames leads people to expect inconsistancy and gives the whole system a very unreliable, unpredictable feel. Other email about OLWM server grabs: >1056853 x11news/x11: >OW Exit notice hangs system causing input queue lock brokens >Status: Desktop integration issue. Marked in bug traq as evaluated. >This is an X-and-NeWS integration issue and is a terribly complicated problem. X11 does not expect that server-internal locking will ever time out. X11 has similar situations to the one mentioned in the bug report where a client grabs the server and then a passive grab triggers. And it works fine. The difference is that the effect of the passive grab doesn't time-out, thereby causing an inconsistent state. >One possibility cited for a fix is to change the server to stop distributing events to synchronous NeWS interests while an X client has the server grabbed. But this might only result in moving the problem around and not in solving the real problem. >According to Stuart Marks, olwm could grab the keyboard and mouse before grabbing the server and that might get around this particular problem. >ACTION: Stuart Marks should be supported in making this change. Stewart, is any of that lazy unfair criticism?
geertj 4y ago
As others have said I think the title was more clickbait-y. Olaf was the person who wrote the in-kernel NFS server so I think he at least appreciated NFS somewhat. The paper makes a few reasonable criticisms many of which are addressed now. My favorite criticism from that paper is that NFS clients reused the source port so that the server can detect whether a new connection is the same client or not. This confuses stateful packet filtering on the network because both connections now have the same 5-tuple and packets on the new connection can look like out of window packets on the old connection. This can get connections blackholed depending on the network. This was fixed a few years ago in the Linux client for NFS v4.1, since that version of the protocol already has a different way to identify clients. Before this was fixed, EFS had to document a workaround.

by smarks 4y ago

chasil 4y ago

If you think that was bad, just listen to what Theo de Raadt had to say. "NFSv4 is a gigantic joke on everyone....NFSv4 is not on our roadmap. It is a ridiculous bloated protocol which they keep adding crap to. In about a decade the people who actually start auditing it are going to see all the mistakes that it hides. "The design process followed by the NFSv4 team members matches the methodology taken by the IPV6 people. (As in, once a mistake is made, and 4 people are running the test code, it is a fact on the ground and cannot be changed again.) The result is an unrefined piece of trash." https://blog.fosketts.net/2015/02/03/vsphere-6-nfs-41-finally/ https://blog.fosketts.net/2015/02/03/vsphere-6-nfs-41-finall...

smarks 4y ago
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.
- Enderboi 4y ago
  The funny thing is that we're running our large NFS servers on OmniOS (with Linux NFS clients), as plugins for a certain large PHP-based blogging platform loves to sprinkle LOCK_EX flocks all over the place. Sadly with a Linux NFS server, lock state eventually corrupts itself to extinction but OmniOS can tick along past 300 days uptime without a problem. Of course.... these issues only show up under production levels of load, and have never been able to be distilled into a reproducable test case. FML, and FNL ( = fricking NFS locking :P)
wahern 4y ago
Trash or not, the demand for the features is there. OpenBSD enjoys the luxury of simply telling people who need more sophisticated features to piss-off, at least until the time a protocol or interface has been hashed out and settled into a static target. Notably, OpenBSD has an IPv6 and IPSec (including IKE) stack second to none. If OpenBSD developers actually had a need for the features provided by NFSv4, I'm sure OpenBSD would have an exceptionally polished and refined--at least along the dimensions they care about--implementation. But they don't. What they do have is a relatively well-maintained NFSv3 and YP stacks (not even NIS!), because those things are important to Theo, especially for (AFAIU) maintaining the build farm and related project infrastructure.
- bgm1975 4y ago
  Yp is NIS. It was renamed by Sun due to the trademark on Yellow Pages. Maybe you’re thinking of NIS+ (which was an abomination). TBH, they are both horrible for their own reasons.
  - wahern 4y ago
    Ah, yes, NIS+. Thank you for the correction. I also had in mind that OpenBSD deliberately and rigorously only refers to "YP" ("Yellow Pee"). Google "OpenBSD" and "NIS" and most of the hits you'll see directly from the OpenBSD project are from commit logs for patches removing accidental usages of "NIS" in initial YP-related feature commits. I'm not quite sure why they do that. I've kind of assumed it's to make clear that they have little interest in addressing vendor compatibility issues, and to emphasize that YP support, such as it is, is narrowly tailored to supporting the needs of the OpenBSD project itself. That's quite different from IPv6, IPSec/IKE, and even NFSv3, where cross-vendor interoperability is a concern (within reason).
    - DonHopkins 4y ago
      Speaking of YP (which I always thought sounded like a brand of moist baby poop towelettes), BSD, wildcard groups, SunRPC, and Sun's ingenuous networking and security and remote procedure call infrastructure, who remembers Jordan Hubbard's infamous rwall incident on March 31, 1987? https://news.ycombinator.com/item?id=25156006 https://news.ycombinator.com/item?id=25156006 https://en.wikipedia.org/wiki/Jordan_Hubbard#rwall_incident https://en.wikipedia.org/wiki/Jordan_Hubbard#rwall_incident >rwall incident >On March 31, 1987 Hubbard executed an rwall command expecting it to send a message to every machine on the network at University of California, Berkeley, where he headed the Distributed Unix Group. The command instead began broadcasting Hubbard's message to every machine on the internet and was stopped after Hubbard realised the message was being broadcast remotely after he received complaints from people at Purdue University and University of Texas. Even though the command was terminated, it resulted in Hubbard receiving 743 messages and complaints, including one from the Inspector General of ARPAnet. I was logged in on my Sun workstation "tumtum" when it happened, so I received his rwall too, and immediately sent him a humorous email with the subject of "flame flame flame" which I've lost in the intervening 35 years, but I still have a copy of his quick reply: From: Jordan K. Hubbard <jkh%violet.Berkeley.EDU@berkeley.edu> Date: Tue, Mar 31, 1987, 11:02 PM To: Don Hopkins <don@tumtum.cs.umd.edu> Subject: re: flame flame flame Thanks, you were nicer than most.. Here's the stock letter I've been sending back to people: Thank you, thank you.. Now if I can only figure out why a lowly machine in a basement somewhere can send broadcast messages to the entire world. Doesn't seem *right* somehow. Yours for an annoying network. Jordan P.S. I was actually experimenting to see exactly now bad a crock RPC was. I'm beginning to get an idea. I look forward to your flame. Jordan Here's the explanation he sent to hackers_guild, and some replies from old net boys like Milo Medin (who said the program manager of the Arpanet in the Information Science and Technology Office of DARPA Dennis G. Perry said they would kick UCB off the Arpanet if it ever happened again), Mark Crispin (who presciently proposed cash rewards for discovering and disclosing security bugs), and Dennis G. Perry himself: From: Jordan K. Hubbard <jkh%violet.Berkeley.EDU@berkeley.edu> Date: April 2, 1987 Subject: My Broadcast By now, many of you have heard of (or seen) the broadcast message I sent to the net two days ago. I have since received 743 messages and have replied to every one (either with a form letter, or more personally when questions were asked). The intention behind this effort was to show that I wasn't interested in doing what I did maliciously or in hiding out afterwards and avoiding the repercussions. One of the people who received my message was Dennis Perry, the Inspector General of the ARPAnet (in the Pentagon), and he wasn't exactly pleased. (I hear his Interleaf windows got scribbled on) So now everyone is asking: "Who is this Jordan Hubbard, and why is he on my screen??" I will attempt to explain. I head a small group here at Berkeley called the "Distributed Unix Group". What that essentially means is that I come up with Unix distribution software for workstations on campus. Part of this job entails seeing where some of the novice administrators we're creating will hang themselves, and hopefully prevent them from doing so. Yesterday, I finally got around to looking at the "broadcast" group in /etc/netgroup which was set to "(,,)". It was obvious that this was set up for rwall to use, so I read the documentation on "netgroup" and "rwall". A section of the netgroup man page said: ... Any of three fields can be empty, in which case it signifies a wild card. Thus universal (,,) defines a group to which everyone belongs. Field names that ... ... Now "everyone" here is pretty ambiguous. Reading a bit further down, one sees discussion on yellow-pages domains and might be led to believe that "everyone" was everyone in your domain. I know that rwall uses point-to-point RPC connections, so I didn't feel that this was what they meant, just that it seemed to be the implication. Reading the rwall man page turned up nothing about "broadcasts". It doesn't even specify the communications method used. One might infer that rwall did indeed use actual broadcast packets. Failing to find anything that might suggest that rwall would do anything nasty beyond the bounds of the current domain (or at least up to the IMP), I tried it. I knew that rwall takes awhile to do its stuff, so I left it running and went back to my office. I assumed that anyone who got my message would let me know.. Boy, was I right about that! After the first few mail messages arrived from Purdue and Utexas, I begin to understand what was really going on and killed the rwall. I mean, how often do you expect to run something on your machine and have people from Wisconsin start getting the results of it on their screens? All of this has raised some interesting points and problems. 1. Rwall will walk through your entire hosts file and blare at anyone and everyone if you use the (,,) wildcard group. Whether this is a bug or a feature, I don't know. 2. Since rwall is an RPC service, and RPC doesn't seem to give a damn who you are as long as you're root (which is trivial to be, on a work- station), I have to wonder what other RPC services are open holes. We've managed to do some interesting, unauthorized, things with the YP service here at Berkeley, I wonder what the implications of this are. 3. Having a group called "broadcast" in your netgroup file (which is how it comes from sun) is just begging for some novice admin (or operator with root) to use it in the mistaken belief that he/she is getting to all the users. I am really surprised (as are many others) that this has taken this long to happen. 4. Killing rwall is not going to solve the problem. Any fool can write rwall, and just about any fool can get root priviledge on a Sun workstation. It seems that the place to fix the problem is on the receiving ends. The only other alternative would be to tighten up all the IMP gateways to forward packets only from "trusted" hosts. I don't like that at all, from a standpoint of reduced convenience and productivity. Also, since many places are adding hosts at a phenominal rate (ourselves especially), it would be hard to keep such a database up to date. Many perfectly well- behaved people would suffer for the potential sins of a few. I certainly don't intend to do this again, but I'm very curious as to what will happen as a result. A lot of people got wall'd, and I would think that they would be annoyed that their machine would let someone from the opposite side of the continent do such a thing! Jordan Hubbard jkh@violet.berkeley.edu (ucbvax!jkh) Computer Facilities & Communications. U.C. Berkeley From: Milo S. Medin <medin@orion.arpa> Date: Apr 6, 1987, 5:06 AM Actually, Dennis Perry is the head of DARPA/IPTO, not a pencil pusher in the IG's office. IPTO is the part of DARPA that deals with all CS issues (including funding for ARPANET, BSD, MACH, SDINET, etc...). Calling him part of the IG's office on the TCP/IP list probably didn't win you any favors. Coincidentally I was at a meeting at the Pentagon last Thursday that Dennis was at, along with Mike Corrigan (the man at DoD/OSD responsible for all of DDN), and a couple other such types discussing Internet management issues, when your little incident came up. Dennis was absolutely livid, and I recall him saying something about shutting off UCB's PSN ports if this happened again. There were also reports about the DCA management types really putting on the heat about turning on Mailbridge filtering now and not after the buttergates are deployed. I don't know if Mike St. Johns and company can hold them off much longer. Sigh... Mike Corrigan mentioned that this was the sort of thing that gets networks shut off. You really pissed off the wrong people with this move! Dennis also called up some VP at SUN and demanded this hole be patched in the next release. People generally pay attention to such people. Milo From: Mark Crispin <MRC%PANDA@sumex-aim.stanford.edu> Date: Mon, Apr 6, 1987, 10:15 AM Dan - I'm afraid you (and I, and any of the other old-timers who care about security) are banging your head against a brick wall. The philsophy behind Unix largely seems quite reminiscent of the old ITS philsophy of "security through obscurity;" we must entrust our systems and data to a open-ended set of youthful hackers (the current term is "gurus") who have mastered the arcane knowledge. The problem is further exacerbated by the multitude of slimy vendors who sell Unix boxes without sources and without an efficient means of dealing with security problems as they develop. I don't see any relief, however. There are a lot of politics involved here. Some individuals would rather muzzle knowledge of Unix security problems and their fixes than see them fixed. I feel it is *criminal* to have this attitude on the DDN, since our national security in wartime might ultimately depend upon it. If there is such a breach, those individuals will be better off if the Russians win the war, because if not there will be a Court of Inquiry to answer... It may be necessary to take matters into our own hands, as you did once before. I am seriously considering offering a cash reward for the first discoverer of a Unix security bug, provided that the bug is thoroughly documented (with both cause and fix). There would be a sliding cash scale based on how devastating the bug is and how many vendors' systems it affects. My intention would be to propagate the knowledge as widely as possible with the express intension of getting these bugs FIXED everywhere. Knowledge is power, and it properly belongs in the hands of system administrators and system programmers. It should NOT be the exclusive province of "gurus" who have a vested interest in keeping such details secret. -- Mark -- PS: Crispin's definition of a "somewhat secure operating system": A "somewhat secure operating system" is one that, given an intelligent system management that does not commit a blunder that compromises security, would withstand an attack by one of its architects for at least an hour. Crispin's definition of a "moderately secure operating system": a "moderately secure operating system" is one that would withstand an attack by one of its architects for at least an hour even if the management of the system are total idiots who make every mistake in the book. ------- From: Dennis G. Perry <PERRY@vax.darpa.mil> Date: Apr 6, 1987, 3:19 PM Jordan, you are right in your assumptions that people will get annoyed that what happened was allowed to happen. By the way, I am the program manager of the Arpanet in the Information Science and Technology Office of DARPA, located in Roslin (Arlington), not the Pentagon. I would like suggestions as to what you, or anyone else, think should be done to prevent such occurances in the furture. There are many drastic choices one could make. Is there a reasonable one? Perhaps some one from Sun could volunteer what there action will be in light of this revelation. I certainly hope that the community can come up with a good solution, because I know that when the problem gets solved from the top the solutions will reflect their concerns. Think about this situation and I think you will all agree that this is a serious problem that could cripple the Arpanet and anyother net that lets things like this happen without control. dennis ------- Also: http://catless.ncl.ac.uk/Risks/4.73.html#subj10.1 http://catless.ncl.ac.uk/Risks/4.73.html#subj10.1 https://everything2.com/title/Jordan+K.+Hubbard https://everything2.com/title/Jordan+K.+Hubbard

DonHopkins 4y ago

Stewart, I think "sucks" is a pretty fair description of a protocol that actually trusted the client to tell the server what its host name is, before the server checked that the host name appears in /etc/exports, without verifying the client's ip address. On a system that makes /etc/exports easily publicly readable via tftp by default. Did you find my criticism of how X-Windows sucks in the Unix Haters Handbook as unfair and un-credible and lazy as you found the book's criticism of NFS? Or my criticism of OLWM and XBugTool, which also both sucked? https://web.archive.org/web/20000423081727/http://www.art.net/~hopkins/Don/unix-haters/x-windows/disaster.html https://web.archive.org/web/20000423081727/http://www.art.ne... Did you ever fix those high priority OLWM bugs I reported with XBugTool that OLWM unnecessarily grabbed the X11/NeWS server all the time and caused the input queue to lock up so you couldn't do anything for minutes at a time? And that related bug caused by the same grab problem that the window system would freeze if you pressed the Help key while resizing a window? Or manage to get OLWM's showcase Open Look menus to pin up without disappearing for an instant then reappearing in a different place, with a totally different looking frame around it, and completely different mouse tracking behavior? That unnecessary song and dance completely ruined the "pinned menu" user experience and pinned menu metaphor's illusion that it was the same menu before and after pinning. While TNT menus simply worked and looked perfectly and instantly when you pinned them, because it WAS the same menu after you pinned it, so it didn't have to flicker and change size and location and how it looked and behaved. Ironically, the NeWS Toolkit was MUCH better at managing X11 windows than the OLWM X11 window manager ever was, because our NeWS based X11 window manager "OWM" was deeply customizable and had a lot more advanced features like multiple rooms, scrolling virtual desktops, tabbed windows supporting draggable tabs on all four edges, resize edges, custom resize rubber banding animation, and pie menus, as well. It also never grabbed and froze the window server, and it took a hell of a lot less time and resources to develop than OLWM, which never lifted a finger to support TNT the way TNT bent over backwards to support X11. NeWS Tab Window Demo -- Demo of the Pie Menu Tab Window Manager for The NeWS Toolkit 2.0. Developed and demonstrated by Don Hopkins: https://www.youtube.com/watch?v=tMcmQk-q0k4 https://www.youtube.com/watch?v=tMcmQk-q0k4 https://web.archive.org/web/19981203002306/http://www.art.net/~hopkins/Don/unix-haters/x-windows/i39l.html https://web.archive.org/web/19981203002306/http://www.art.ne... >I39L window management complicates pinned menus enormously. TNT menus pin correctly, so that when you push the pin in, the menu window simply stays up on the screen, just like you'd expect. This is not the case with XView or even OLWM. Under an I39L window manager, the Open Look pinned menu metaphor completely breaks down. When you pin an X menu, it dissappears from the screen for an instant, then comes back at a different place, at a different size, with a different look and feel. If you're not running just the right window manager, pinned menus don't even have pins! There is no need for such "ICCCM compliant" behavior with TNT menus. When they're pinned, they can just stay there and manage themselves. But were TNT windows managed by an external I39L window manager, they would have to degenerate to the level of X menus. https://web.archive.org/web/20000602215640/http://www.art.net/~hopkins/Don/unix-haters/x-windows/xbugtool.html https://web.archive.org/web/20000602215640/http://www.art.ne... >I could go on and on, but I just lost my wonderful xbugtool, because I was having too much fun way too fast with those zany scrolling lists, so elmer the bug server freaked out and went off to la-la land, causing xbugtool to lock the windows and start "channeling", at the same time not responding to any events, so when I clicked on the scrolling list, the entire window system froze up and I had to wait for the input queue lock to break, but by the time the lock finally broke (it must have been a kryptonite), xbugtool had made up its mind, decided to meet its maker, finished core dumping, and exited with an astoundingly graceful thrash, which was a totally "dwim" thing for it to do at the time, if you think about it with the right attitude, since I had forgotten what I wanted to file a bug against in the first place anyway, and totally given up the idea of ever using bugtool to file a bug against itself, because bugtool must be perfect to have performed so splendidly! From the news-makers archive: >From: Skip Montanaro <crdgw1!montnaro@uunet.uu.net> Date: Feb 16, 1990 >Charles Hedrick writes concerning XNeWS problems. I have a couple of comments on the XNeWS situation. >The olwm/pswm interface appears (unfortunately) to be stable as far as Sun is concerned. During XNeWS beta testing I complained about the lack of function key support, but was told it was an OpenLook design issue. (NeWS1.1 supported function keys, and you could do it in PostScript if you like.) Sun likes to tout how OpenLook is standard, and was designed by human factors types. As far as I'm concerned, nobody has had enough experience with good user interfaces to sit down and write a (horribly large, hard-to-read) spec from which a window manager with a "good" look-and-feel will be created. I'm convinced you still have to experiment with most user interfaces to get them right. >As a simple example, consider Don Hopkins' recent tabframes posting. An extra goody added in tabframes is the edge-stretch thingies in the window borders. You can now stretch one edge easily, without inadvertently stretching the other edge connected to your corner-stretch thingie. Why did the OpenLook designers never think of this? SunView had that basic capability, albeit without visible window gadgetry. It wasn't like the idea was completely unheard of. >I agree that running the XNeWS server with an alternate window manager is a viable option. Before I got my SPARCStation I used XNeWS in X11ONLY mode with gwm, which was the only ICCCM-compliant window manager I had available to me at the time. If you choose to use twm with XNeWS, I recommend you at least try the X11R4 version. >From: William McSorland - Sun UK - Tech Support <will@willy.uk> Date: May 14, 1991 Subject: 1059370: Please evaluate >Bug Id: 1059370 Category: x11news Subcategory: olwm Bug/Rfe: rfe Synopsis: OLWM does a Server Grab while the root menu is being displayed. Keywords: select, frame_busy, presses, left, mouse, server, grabbed Severity: 5 Priority: 5 Description: >Customer inisisted on having this logged as a RFE and so:- >When bringing up the root menu inside OW2.0 the window manager does a Server Grab hence forcing all its client applications output to be queued by the server, but not displayed. >The customer recommends that this should be changed to make olwm more friendly. >Apparently a number of other window managers don't do a server grab while the root menu is being displayed. >From: Don Hopkins <hopkins@sun.com> Subject: 1059974: Bug report created >Bug Id: 1059974 Category: x11news Subcategory: server Bug/Rfe: bug Synopsis: I have no mouse motion and my input focus is stuck in xbugtool!!! Keywords: I have no mouth and I must scream [Harlan Ellison] Severity: 1 Priority: 1 Description: >This is my worst nightmare! None of my TNT or XView applications are getting any mouse motion events, just clicks. And my input focus is stuck in xbugtool, of all places!!! When I click in cmdtool, it gets sucked back into xbugtool when I release the button! And I'm not using click-to-type! I can make selections from menus (tnt, olwm, and xview) if I click them up instead of dragging, but nobody's receiving any mouse motion! >I just started up a fresh server, ran two jets and a cmdtool, fired up a bugtool from one of the jets (so input focus must have been working then), and after xbugtool had throbbed and grunted around for a while and finally put up its big dumb busy window, I first noticed something was wrong when I could not drag windows around! >Lucky thing my input focus ended up stuck in xbugtool! >The scrollbar does not warp my cursor either... I can switch the input focus to any of xbugtool's windows, but I can't ... -- oomph errrgh aaaaahhh! There, yes! >Aaaaah! What a relief! It stopped! I can move my mouse again!! Hurray!!! It started working when I opened a "jet" window, found I could type into it, so I moved the mouse around, the cursor disappeared, I typed, there were a couple of beeps, I still couldn't find the cursor, so I hit the "Open" key, the jet closed to an icon, and I could type to xbugtool again! And lo and behold now I can type into the cmdtool, too! Just by moving my cursor into it! What a technological wonder! Now I can start filing bug reports against cmdtool, which was the only reason I had the damn thing on my screen in the first place!!! I am amazed at the way the window system seems to read my mind and predict my every move, seeming to carry out elaborate practical jokes to prevent me from filing bugs against it. I had no idea the Open Windows desktop had such sophisticated and well integrated interclient communication! >From: Don Hopkins <hopkins@sun.com> Subject: 1059976: Bug report created Date: May 21, 1991 >Bug Id: 1059976 Category: x11news Subcategory: olwm Bug/Rfe: bug Synopsis: OLWM menus are inconsistant with the rest of the desktop, Keywords: pinned menus, defaults, tracking, inconsistant look and feel, yet another open look toolkit Severity: 2 Priority: 2 Description: >You can't set the default of a pinned menu by holding down the control key and clicking over an item. >Pressing the middle button over the default of a pinned menu erases the default ring. >You can't set the default of a unpinned menu by pressing the control key then the popping it up by pressing the MENU button on the mouse. >When you're tracking a menu, and press the control key, the highlighting changes properly, from depressed to undepressed with a default ring, but when you release the control key before releasing the MENU button on the mouse, the highlighting does not change back to depressed without a default ring. Instead it stays the same, then changes to un-depressed without a default ring at the next mouse movement, and you have to move out and back into the menu item to see it depressed again. >When you're dragging over a menu, then press the control key to set the default, then release the mouse button to make a selection, without releasing the control key, OLWM menus are stuck in default-setting mode, until the next time it sees a control key up transition while it is tracking a menu. >Clicking the SELECT button on the abbreviated menu button on the upper left corner of the window frame (aka the close box or shine mark) should select the frame menu default, instead of always closing the window. >The tracking when you press and release the control key over a menu pin is strange, as well. Push-pins as menu defaults are a dubious concept, and the HIT people should be consulted for an explaination or a correction. >When you press the menu button in a submenu, it does not set the default of the menu that popped up the submenu, the way XView and TNT menus do. This behaviour also needs clarification from the HIT team. >Pinned OLWM menus do not track the same way as unpinned menus. When you press down over an item, and drag to another item, the highlighting does not follow the mouse, instead the original item stays highlighted. The item un-highlights when the mouse exits it, but the menu highlighting should track the item underneath the cursor when the user is holding the mouse button down, just like they do with a non-pinned menu. The current behavior misleads you that the item would be selected if the button were released even though the cursor is not over the menu item, and is very annoying when you press down over a pinned menu item and miss the one you want, and expect to be able to simply drag over to the one you meant to hit. >If we are crippling our menus this way on purpose, because we are afraid Apple is going to sue us, then Apple Computer has already done damage to Sun Microsystems without even paying their lawyers to go to court. We licensed the technology directly from Xerox, and we should not make our users suffer with an inferior interface because we are afraid of boogey-men. >In general, OLWM is yet another OpenLook toolkit, and its menus are unlike any other menus on the desktop. This is a pity because the user interacts so closely with OLWM, and the conspicuous inconsistancy between the window manager and the Open Look applications that it frames leads people to expect inconsistancy and gives the whole system a very unreliable, unpredictable feel. Other email about OLWM server grabs: >1056853 x11news/x11: >OW Exit notice hangs system causing input queue lock brokens >Status: Desktop integration issue. Marked in bug traq as evaluated. >This is an X-and-NeWS integration issue and is a terribly complicated problem. X11 does not expect that server-internal locking will ever time out. X11 has similar situations to the one mentioned in the bug report where a client grabs the server and then a passive grab triggers. And it works fine. The difference is that the effect of the passive grab doesn't time-out, thereby causing an inconsistent state. >One possibility cited for a fix is to change the server to stop distributing events to synchronous NeWS interests while an X client has the server grabbed. But this might only result in moving the problem around and not in solving the real problem. >According to Stuart Marks, olwm could grab the keyboard and mouse before grabbing the server and that might get around this particular problem. >ACTION: Stuart Marks should be supported in making this change. Stewart, is any of that lazy unfair criticism?

geertj 4y ago

As others have said I think the title was more clickbait-y. Olaf was the person who wrote the in-kernel NFS server so I think he at least appreciated NFS somewhat. The paper makes a few reasonable criticisms many of which are addressed now. My favorite criticism from that paper is that NFS clients reused the source port so that the server can detect whether a new connection is the same client or not. This confuses stateful packet filtering on the network because both connections now have the same 5-tuple and packets on the new connection can look like out of window packets on the old connection. This can get connections blackholed depending on the network. This was fixed a few years ago in the Linux client for NFS v4.1, since that version of the protocol already has a different way to identify clients. Before this was fixed, EFS had to document a workaround.