Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

More, less, and a story of typical Unix fossilization

utcc.utoronto.ca

Post reply on HN
Print view View original

101–110 of 127 posts

Re: More, less, and a story of typical Unix fossilization

#101

Post by RubyPinch »

akavel wrote: post #75

Interestingly, it occurred to me that NixOS might be in perfect position to enable painless "gradual migrations" of tooling. Imagine alternative history of UNIX, where NixOS was invented really long time ago, before 'less' was created. Now, imagine we're Mark Nudelman and we want to add fancy features to 'more' (instead of creating a new tool named 'less'). We could do this freely, and all tools depending on peculiar…

I'd be asking the question of wether anything depended on `more` that couldn't depend on `less` already, but instead depends on more because more is not less.

Or, in other words, maybe the issue is cultural instead of technical, which would in practice, result in new users going to either more (the relic) or less (the bloated), depending on their views, instead of all new users going to less

edit: reading through the rest of the comments here, it seems a lot of people prefer more, for various reasons!

Re: More, less, and a story of typical Unix fossilization

#102

Post by pmontra »

Sylos wrote: post #72
pbhjpbhj wrote: post #27

Earlier quoted context omitted.

There's "most" pager discussed here a week or so ago, too. (Incidentally that link returns a blank page for me on FF mobile.)

Posting this here, too, for visibility: The page works for me when I tell my browser to request the desktop site.

Ops, I realized that I configured my mobile browsers to request the desktop sites. It's more convenient on a tablet.

    curl -A 'Mozilla/5.0 (Linux; Android 4.0.4; Galaxy Nexus Build/IMM76B) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.133 Mobile Safari/535.19' http://www.unix.com/man-page/linux/1/pg/
returns nothing so it's definitely a mobile unfriendly site.

Re: More, less, and a story of typical Unix fossilization

#104

Post by Twirrim »

sjellis wrote: post #15

I've used Linux for a decade-and-a-half, but I've never totally loved the shell, because of the need to learn this sort of pointless arcana. PowerShell was a massive step forward, and I had hoped that an Open Source, cross-platform equivalent would develop so that we could get past the current local maxima of 1970s-era design. It's rather weird that the Open Source equivalent of PowerShell is now...PowerShell. Even i…

> There are now new Linux users starting every day, and asking them to learn that less is better than more is not funny.

When do you even need to tell them this? Does it fundamentally change how they use the tool somehow? No, they'll see that you pipe stuff through less and that's it. Heck, I've been using Linux for 15+ years, and about 10 of those full time. The first I ever heard that "less is more" was probably ~3 years ago. It just doesn't matter.

What you're complaining about is esoteria (that is still littered all over the Windows ecosystem, e.g. the fingerprints of 8.3 file names still persist, long after it ceased to be a thing)

Re: More, less, and a story of typical Unix fossilization

#105

Post by Annatar »

qwertyuiop924 wrote: post #66
Annatar wrote: post #17

From the article: I am not a fan of Solaris's long standing refusal to touch anything. This is what people often deeply misunderstand about traditional UNIX operating systems: one of Solaris' greatest features, in stark contrast to GNU/Linux, is the insistence on not breaking backward compatibility. Solaris has however delivered less(1) as standard since Solaris 8, so there is nothing stopping one from configuring th…

Well, what about new features that don't break compat? Have they optimized grep the way GNU did? And the fact is, when there's a piece of core that nobody uses, and has since been replaced by superior tooling, The Right Thing to do is to rip it out, and link to said superior tooling if it has a compat mode. I mean, it's not like Solaris still has ptrace or /dev/poll.

And the fact is, when there's a piece of core that nobody uses, and has since been replaced by superior tooling, The Right Thing to do is to rip it out,

...The only way that could ever work without breaking existing software running in the wild would be for that superior tooling to be backwards compatible. SunOS (illumos) does this all of the time. For example, GNU options like -C have been added to SVR4 tar(1) on illumos, thereby enhancing, but not breaking existing functionality.

Otherwise, how would you determine whether someone isn't using something, and that on every Solaris / illumos system on the planet?

Have they optimized grep the way GNU did?

I don't know about grep(1) in particular, we have fgrep(1) on illumos for that, which comes all the way from AT&T's SVR4. We also have egrep(1) in addition to grep(1). HP-UX for example, being a SVR4 system, has fgrep(1) and egrep(1) in addition to grep(1) as well. I use fgrep(1) every day; only when I need to use regular expressions do I use grep(1).

I know cat(1)'s been optimised. If you're curious enough, you can check out Solaris's grep(1) code here:

https://github.com/illumos/illumos-gate/tree/master/usr/src/...

Lupus in fabula: you can also see that the -H option has been added to grep(1), which illustrates my point that illumos does this all of the time[1].

I mean, it's not like Solaris still has ptrace or /dev/poll.

?

  % ls -l /dev/poll
  lrwxrwxrwx   1 root     root          29 Jul 24  2013 /dev/poll -> ../devices/pseudo/poll@0:poll
  % man ptrace
  Standard C Library Functions                           ptrace(3C)

  NAME
       ptrace - allows a parent process to control the execution of
       a child process

  SYNOPSIS
       #include 
       #include 

       int ptrace(int request, pid_t pid, int addr, int data);
  ...
  ...
  ...
  % uname -srpmi
  SunOS 5.10 i86pc i386 i86pc
...so I'm baffled by your statement. Did you mean to write the opposite? What were you actually trying to say?

[1] https://github.com/illumos/illumos-gate/commit/41599e9fdccb4...

Re: More, less, and a story of typical Unix fossilization

#107

Post by qwertyuiop924 »

Annatar wrote: post #105
qwertyuiop924 wrote: post #66

Earlier quoted context omitted.

Well, what about new features that don't break compat? Have they optimized grep the way GNU did? And the fact is, when there's a piece of core that nobody uses, and has since been replaced by superior tooling, The Right Thing to do is to rip it out, and link to said superior tooling if it has a compat mode. I mean, it's not like Solaris still has ptrace or /dev/poll.

And the fact is, when there's a piece of core that nobody uses, and has since been replaced by superior tooling, The Right Thing to do is to rip it out, ...The only way that could ever work without breaking existing software running in the wild would be for that superior tooling to be backwards compatible. SunOS (illumos) does this all of the time. For example, GNU options like -C have been added to SVR4 tar(1) on il…

Huh. Yeah, no, they're still there. Okay. I have no idea what I meant. Could have sworn somebody axed ptrace, though.

My main point was that if you have a superior utility that doesn't break compatability, like less, than why ship the original? Less is better than more, and it doesn't break compatability in any way I know. That's why setting it as $PAGER works.

The fact is, a lot of superior tooling is backwards compatible. PCRE (although superior is up for debate) is fairly compatible with extended regex, GNU tar is compatible with posix tar, both syntactically, and semantically with the aid of -H. Heck, it's compatible with the v7 archive format.

Re: More, less, and a story of typical Unix fossilization

#108

Post by guitarbill »

Annatar wrote: post #61
guitarbill wrote: post #51

Earlier quoted context omitted.

> one of Solaris' greatest features Features are use-case specific. One person's feature is another person's bloat. (Personally, I side with the article author on this.)

Do you deliver any software for the platform you use, and if so, do you not mind when things suddenly stop working? Or, are you responsible for delivering any services, and if so, do you not mind when someone else's changes cause you an outage? Perhaps you have some private automation in place; do you not mind if your automation breaks because of someone else? Apropos bloat, illumos is the only operating system codeb…

I see this as a necessary consequence of being human. Sometimes, a genius comes along and gets the design and implementation right for years to come. Most of the time, people try their best. But nobody can really see into the future.

I'm happy enough if people say "okay, we didn't get this quite right, but we learned and we've made it better". And if the new approach isn't compatible, well okay. The short-term pain is usually worth moving forward in the long-term.

And when this happens, it's usually not a technical issue anymore, but a communication issue, which is a way harder problem to solve. If your solution to the communication problem is technical, i.e. let's always maintain backwards compatibility, then there's still the issue of communicating what the new, preferred method is. So I feel that if you have great communication with the people who care, it shouldn't impact them badly in the first place.

The danger of backwards compatibility is maintenance cost, and stifling new ideas to solve an existing problem better - people won't bother, because the effort of making something new would be overshadowed by the effort to retro-fit old behaviour.

Still though, I get the point of changing stuff just for the sake of change is bad. I'll ignore the hyperbole about illumos though.

Re: More, less, and a story of typical Unix fossilization

#109

Post by rootbear »

xioxox wrote: post #19

One advantage I find of more over less, is that it doesn't clear the terminal on exit. It's often nice to see what you have looked at above the command prompt. There is a "-X" option for less, but this also breaks mouse wheel scrolling.

Those horrid alt-buffer init and exit strings in terminfo and termcap are the bane of my existence. I almost never want that behavior, particularly when I've got a relevant section of a man page on the screen and want it to STAY THERE when I quit out of the pager. I use -X in less, but I really want a more universal solution, so I use a terminal type that doesn't have those strings, usually xterm-noapp. But it's not always available.

I'm not sure what you mean about -X and mouse scrolling.

Re: More, less, and a story of typical Unix fossilization

#110

Post by sjellis »

Twirrim wrote: post #104
sjellis wrote: post #15

I've used Linux for a decade-and-a-half, but I've never totally loved the shell, because of the need to learn this sort of pointless arcana. PowerShell was a massive step forward, and I had hoped that an Open Source, cross-platform equivalent would develop so that we could get past the current local maxima of 1970s-era design. It's rather weird that the Open Source equivalent of PowerShell is now...PowerShell. Even i…

> There are now new Linux users starting every day, and asking them to learn that less is better than more is not funny. When do you even need to tell them this? Does it fundamentally change how they use the tool somehow? No, they'll see that you pipe stuff through less and that's it. Heck, I've been using Linux for 15+ years, and about 10 of those full time. The first I ever heard that "less is more" was probably ~3…

The Linux command-line experience is mostly composed of esoterica, and less vs. more is actually one of the least bad of a thousand paper cuts. I just couldn't resist taking a dig at the pun.

One thing that this thread has really brought into focus for me is that we treat the *NIX shells differently, because we are used to them, but IMO we ought to hold the shell to the same standards that we'd apply to any programming environment. If a new programming language with a REPL shipped today that was the quality of the shell experience that we've currently got, we'd think that it was ridiculous.

Post reply on HN