Why is my bug report a "snark", I have in good faith reported what I consider a bug with Ubuntu, namely the functionality that is being added to the GUI is not also being consistently added to the CLI tools that some many of us rely on.
You have chosen to mark my bug report "invalid", which is your total prerogative and I have total respect for you doing that.
I am saddened, however, you have chosen to resort to personal insults (being labeled a snark nearly made my monocle drop out!), rather than focusing on the technical issues presented.
grep --universe would be a good shortcut, except that i think we all agree this important functionality should be present by default. showing these results from places other than my local computer should be opt-out! how about grep --no-universe ?
While this is amusing, it's also rather disrespectful.
You may not agree with the decision by the Ubuntu team to incorporate a feature...and that's fine. There are plenty of ways to voice that opinion (blogs, email, forum).
Putting patently invalid(joke) bug reports in a system that's designed for actionable bug fixes just makes life a bit more troublesome for people actually trying to fix things. Harassing them about it through this channel seems like a waste of their time.
Seems like Shuttleworth responded to this gracefully, though. :)
>Putting patently invalid(joke) bug reports in a system that's designed for actionable bug fixes just makes life a bit more troublesome for people actually trying to fix things. Harassing them about it through this channel seems like a waste of their time.
Let's consider protest via sit-ins at Local Business Foo for its socially-irresponsible but entirely-legal policy/action of Bar. There are plenty of places to protest those actions/policies. Various municipal bodies (city council, chamber of commerce) and private bodies (better business bureau, etc.) are all channels designed for handling complaint. It is precisely because of these channels exist that more a unconventional method of complaint is more notable and thus potentially more effective. In such cases involving a local business, you are most definitely wasting someone's time, far beyond the bounds of deleting or invalidating a bug tracking ticket.
As a qualification, I recognize that, depending on the topic of protest, there can be a gap/disconnect in the severity of the topic of protest. The cultural go-to for the words "sit-in protest" evokes imagery of the American civil-rights era, whereas this is an affiliate monetization scheme for an open source operating system. Yet there are other topics which have drawn sit-in protests over the decades, and drawing upon these I feel that my metaphor is apt.
(edit: eckyptang beat me to the punch while I was typing this longwinded and nuanced response)
Furthermore, to the sit-in analogy, I would never have heard of this "grep -R" bug if not for the novel protest medium. I think this alone gives credence to its effectiveness.
I think many HN readers will agree that an inconsistent or nonsensical user experience is, in many situations, a bug.
As noted in the comments on the bug, there is a disconnect between the features available at the command-line and available through the GUI; except in the
Second, when you have issues like these[1] popping up, as well as the corresponding privacy concerns, I think it's perfectly fine to illustrate that with a polite bug that illustrates more clearly how silly it is to integrate this feature into an operating system (by default).
A sit-in-protest has some properties of a physical DoS (denial of service). This was mere words, and no great quantity of them.
This to me looked more like a good old fashioned cleverly-constructed reductio ad absurdum argument and Launchpad seems an entirely appropriate forum for such feedback.
$> cd ~/Movies/Avengers
... people who changed into this directory were also interested in
Marvel Avengers Assemble [DVD] £10.00
$> ls ~
Desktop Downloads Movies Music Pictures
... related items
Intelliplug - Desktop Version £12.95
$> gcc -o test test.c
test.c:1:22: iostream.h: No such file or directory
... people who encountered this error often purchase
GCC For Professionals [Hardcover] £12.95
It amazes me how easily this whole thing could have been prevented if they had just made the Amazon results show up in a separate shopping lens instead of the default lens.
Then even if it's pre-installed there'd be some reasonable expectation that a program designed to show you shopping selections would have to connect to a 3rd party server and send your query.
The obvious solution that was missed is 2 versions.
You have a paid version with no Amazon integration, and a free version with Amazon enabled by default.
This works 3 ways:
(1) The people who don't want amazon, but don't want to pay can just modify the free version. No big deal, small amount of effort to get ads out of your free software.
(2) Lots of people end up paying for the software, not because they don't want to be bothered modifying the free version, but because they actually want to support the product.
(3) They still get tons of revenue from all of the people that download the free version, but never turn the Amazon off.
Almost nobody complains, and everyone wins.
The solution that they chose is probably the worst possible option, and has put the entire operating system's future at risk.
What amazes me is that people make it sound as if they did not consider this. Of course what they considered doing that but also realized that it will raise very little revenue since 99.99% of folks will not click on the Shopping lens.
With this way, people are forced to see Amazon results and a few of them clicking on irrelevant results and buying will result in a lot more revenue comparatively given that it's certainly an affiliate deal.
It's just a total misfire to take Linux users, many of whom are in the Venn diagram intersection of "computer savvy" and "libre software advocate", and then try to force them to watch advertisements on their own desktop.
Even people that don't know computers would probably prefer to use Windows or OS X, since that's going to be a nicer experience.
Can someone explain the context of this? I'm not getting the references. I mean, I know what grep is, and I know the -R option, but ...
Is the joke that grep obviously has nothing to do with searching a server you're not on, and the submitter is pretending to be someone who expected that it would search Amazon for results? If so, that's stupid, and not even a clever joke.
However, from some of the comments, it sounds like real users (ones actually competent enough to be using grep) are expecting this functionality -- perhaps it doesn't work on some Amazon storage site?
The decision to include Amazon results (by default!) is not in itself a terrible move, but it is an incorrect one.
The fact that it is so patently incorrect to so many outside observers forces me to consider whether the internal vision of the project is completely distorted. No, it's not a big deal, it's just a silly & inappropriate use of your time, and potentially a symptom of a distressing detachment from the real.
Sarcasm? Not the best counterexample, as that's how lots of bots work. The AI engine does not exclusively work by rendering the scene and attempting to visually identify targets.
I imagine you'd read from /dev/random, if you wanted to play as well as I do. All joking aside, I imagine that one could easily write a bot that allowed one to give it heuristics via STDIN or a command line parameter.
I doubt many would do it this way, but it would be consistent with the unix design ethos. One program would manage the Playing the Game and perhaps providing an API for interacting with the game, or even a pluggable section of games, and another would handle generating heuristics (or retrieving them).
I suppose some people might find a use for a CLI interface to the dash's search engine. Changing the behaviour of `grep -R` is definitely not the correct answer, though.
If you want a CLI equivalent of "ubuntu-dash", then you have to make one. grep is not it.
And as far as I am concerned, anyone who honestly finds themselves wishing cli tools worked like gui tools should knock themselves out. I'm sure plenty of people would find it useful.
You can elegantly present advertising and other non-essential elements alongside the main content of a GUI interface.
There is no elegant way to do this with a CLI interface since it is not a static interface, it is a stream of characters. Anything that's not content will have to be inline with user-generated input and output. It would be like a weather app with ads in the middle of the sun icon.
The amazon results are effectively inline with regular results (placed just after, but with the same appearance). There's no reason grep could not also list a few amazon products with URLs after the regular results.
This is absolutely the only way such a feature could be sanely realized, and it would require so many invasive changes it is absurd.
Off the top of my head you would need to patch glibc, all the major shells, probably half of coreutils, anything that daemonizes similar to nohup (including screen and tmux, god knows how many CPAN modules), ...
It could write the output to stderr. Or only write it if stdout is a terminal. Or create a new window that temporarily overlays the xterm running the command.
Yes, amazon-enabled dash and grep/find/whatever have different functionality. But that's a recent change. Previously, dash had exactly the same functionality. That's the entire point. You add a feature here, you add the same feature there.
So now grep prints advertisements if I have it print to a tty, but not if I have it print to a pipe that goes to a pager? Which I almost certainly would be doing if advertisements are pushing my output over 20 or so lines? That is your idea of usability? Brilliant, just brilliant. I suppose I shouldn't even bother to ask what happens if I have tty output being consumed by another program.
>Or create a new window that temporarily overlays the xterm running the command.
You have got to be kidding me. This is a joke.
>Previously, dash had exactly the same functionality
The exact same functionality of which? And I rather doubt that is true.
>You add a feature here, you add the same feature there.
No. No you do not. Not when there is standardized. And in this case the "here"/"there" relationship has not even been established for "ubuntu-dash"/grep, making this extra idiotic.
A lot of console apps dump extra data to stderr, sounds good to me. Especially because if you page the output in less the ads will stay on the screen after you're done :D
Well, aside from blowing the signal/noise ratio of stderr out of the water, I suppose it would be fairly entertaining at first to see log files get filled with advertisements.
Not sure whether they should mimic GUI tools, however having tools which provide a graphical user interface, but are fully functional (or at least as much as is possible) from the CLI is the ideal way for a program to be in my opinion.
Where applicable, a command line option can be a great supplement when something that can be achieved via the GUI . For example, encoding a video to a certain codec, having a visual wrapper on this is a nice to have if converting one video or a few videos. However if that same application allows the ability to encode thousands of videos using the CLI option, its an added ability that is appreciated.
Just throwing out a quick response (I'm not GP) but because they are different interfaces. While they both may display the same content and in the broader overall sense behave similarly, how you interact with the content and program itself is different.
No, because the suggestion behavior is a direct function of the UI. I may expect my shell to offer suggestions or autocomplete based on previous history, however. With either program, I expect them to both perform the core task of "download stuff".
Dash and grep may have different interfaces, but if their core purpose is "search stuff", it is not wholly unreasonable to expect them to be able to search the same stuff.
[grep is probably the wrong tool. perhaps the output should be included in find instead.]
As I said, they are the same tool only in the most superficial of senses. Is the purpose of this ubuntu thing even to grep input streams or files? Or did the submitter of this 'bug' actually mean to file a bug for slocate, mlocate, or find? Does it do both? These tools have completely different purposes and uses.
PS. Is this thing seriously called dash? If so, that is terrible. The name 'dash' is already taken... in the FOSS world... by Ubuntu's daddy distro Debian. Hell, Googling "ubuntu dash" returns first results for the proper dash. What the hell were they thinking?
1. Why on earth wouldn't you want url suggestion/completion for cURL? If there's one place that benefits from a lack of typing it's command-line tools (which is why modern shells all have command and file tab completion).
2. Browsers like 'links' and 'w3m' go so far as to implement mouse support so you can emulate a GUI on the console. Why not for cURL? Just because it has a billion obscure command-line arguments doesn't mean it's a great idea to keep it that way. With a console ncurses UI for cURL I could pick all the options I wanted quickly instead of paging through dozens of man page options, then copying them down with the argument I wanted and re-typing them in line.
I don't think shells should suffer from a lack of innovation just because everyone's obsessed with JavaScript.
And that is rather the point is it not? If you want to add completion to curl, you don't. Because that is a task for another program. If you want to add amazon searching to grep, you don't. Because that is a task for another program.
My point was that command-line completions are possible, and are, in fact, pretty sophisticated. Despite my using 'zsh' as the meme, I'm much more a bash user myself, but even its commandline completions are extensive, and include the ability to suggest completions, alternatives, and the like. Commands such as ssh will utilize various resources to suggest hostname completions and the like.
Whether and how desirable this is is quite the different question. But it's very technically feasible.
>Please can you change the grep warez to have this feature, and just install it on my machine while I'm down the pub, after all you do "erm, have root", so it should be easy for you to do :-)
The thing with LFS is that it would cause Linux users to learn. Not necessarily a bad thing. And I would predict it could lower their tolerance for the lots of the garbage that many ditributions force on them. (Like this brilliant move by Ubuntu!) Who knows, it could lead to a more DIY capable userbase.
They would not have to ask anyone how to remove things or plead with decision-makers to implement their desired changes, they'd just do it themselves.
But yeah, from what I know the Arch Linux distribution imposes a very minimal amount of "pre-configuration".
I've always found it easier to add stuff to a bare bones OS configuration than to remove it from a pre-configured one (you have to thoroughly understand what you're removing first; it's easy to break someone else's delicate Rube Goldberg contraption). But maybe that's just me.
>The thing with LFS is that it would cause Linux users to learn. Not necessarily a bad thing.
This is exactly why I stopped using RHEL and other distros back in the late 90's. I am very interested in learning - to some extent. Writing my own goddamned drivers for my ADSL modem was not what I had in mind. Canonical and Ubuntu have made huge strides forward for Linux in the marketplace.
Yeah, but who said anything about writing drivers? Very few people can do that. How about just really basic stuff, like how to not have ads for Amazon popping up when there is no need?
The driver issue is, in my opinion, the single biggest problem with not using Windows or Mac. If you just jump right into that issue i.e. that the latest driver for your peripehral is not going to be available for some time and ignore all the other benefits of Linux and other UNIX-like systems, then you could pretty easily conclude these systems are worthless. Hardware manufacturers don't care about them.
They only care about Windows and Mac.
But we all know these other systems like Linux are far from worthless.
Clearly, there is some middle ground.
You can still do a heck of a lot without the source code for the 2012 driver for Whiz Bang Hardware Component.
If Canonical and Ubuntu decided not to accept any binary blobs I wonder if the "strides" would seem as huge.
These days Ubuntu has made some seriously poor decisions; I won't deny that (Unity is a joke, this Amazon thing is a huge lol). But Canonical was vital in the push to get Linux on the desktop and to be accepted as more than a "hacker's playground" that is too hard to use for the average person.
Chromebooks and other low-cost appliances like it are successful in large part because of how easy Ubuntu/Canonical made it to transfer into the Linux world from Windows.
I personally use an Ubuntu 11.x build for everything these days (minus some plain Debian builds on my ARM7 devices), and I really like what they've done for Linux - even if the present stuff they've done has been a little stupid.
>akeane, please stop with the snark.
Why is my bug report a "snark", I have in good faith reported what I consider a bug with Ubuntu, namely the functionality that is being added to the GUI is not also being consistently added to the CLI tools that some many of us rely on.
You have chosen to mark my bug report "invalid", which is your total prerogative and I have total respect for you doing that.
I am saddened, however, you have chosen to resort to personal insults (being labeled a snark nearly made my monocle drop out!), rather than focusing on the technical issues presented.