NGS: Next Generation Unix Shell - <AUTHOR> https://github.com/ilyash/ngs/ <comment><USER2> I'm sure we can all agree that the current state of shells needs some work, but I don't think inventing a new one is the right solution. I'm a huge fan of the fish shell, but in the real world, it never seems to be installed across the farm, and convincing the older SysAdmins to install it is more trouble than it's worth.

We should be focusing on saner bash defaults, since it's the most common shell in use. We shouldn't have to remember these large list of gotchas, and pitfalls that shouldn't be there in the first place. A few people out there are trying to recreate common utilities such as ls or cp, and while I welcome the change, I feel it should be part of the actual gnu coreutils package, and not a new project: [https://bsago.me/exa/](https://bsago.me/exa/)

<comment><USER3>
        We should be focusing on saner bash defaults, since it's the most common shell in use.

That kind of work is not glamorous and highly controversial. Ideally there should be some sort of cross distro/OS working group (Debian/Ubuntu, Red Hat, SUSE, FreeBSD, NetBSD, OpenBSD, Mac OS X, etc.), similar to the working groups that standardize the web, where such proposals can be made, voted on and adopted.

For example there should be no reason in 2016 why a sane solution can't be found for having almost every bash installation recognize all keys on the keyboard (i.e. arrow keys wouldn't produce ^A sequences or similar).

Another thing that would be sorely needed but would involve a much higher volume of work would be a template, at least for all GNU utils, which they use to define they options, parameters, arguments, whatever. And by "template" I mean library, actual working code they could include and configure.

Instead of each shell (bash, zsh) having to come with a million small scripts that configure auto completion, these shells could just query the standard- compliant tool for its usage and would receive a standardized reply with everything. Powershell has something like this and it is a great idea.

<comment><USER4> I've been using -nix for almost 20 years. I've used everything from ksh on SunOS 2.6 (Solaris?? what's that) to oh-my-zsh (for 3 years, before happily graduating to oh-my-fish). I grew up on Slackware 6 waiting hours and hours for a 2.2 kernel build to finish. In high school, FreeBSD 4.3 kernel mods took up more time than booze and women. My 3 year puppy love for oh-my-zsh dimmed as I transitioned to a more sane, less emotional woman - oh-my-fish.

I hate to admit it, but Microsoft just _got it right_ with Powershell. Standardizing the convention with an intuitive Verb-Noun, the out of the box documentation with -examples, -full, etc goes into so much detail that if everyone used it, there wouldn't be any dumb "How does I move directory??" questions on Stackoverflow (well, there'd be less at least).

Don't know a command? Show-Commands and type in 'network' to see what's available. Don't see it there? Go get a Powershell script (often offered by vendors like VMware and Citrix, making devop lives easier). I remember spending _weeks_ trying to get my dual-boot machine (FBSD / Win2k) Cygwin/msys setup to work well on my P3 600 at 12 or 13. Now I can just Feature install Bash and get a native binary. Let me say that again -- now, I can Feature install Bash on Windows jeeebus. QT is LGPL. CLR is open source. Visual Studio Community (basically Professional) is free (unless you need historical debugging then Ultimate's going to cost a lot). Satya + Meijers + Hanselman et al have made favor Microsoft so hard, despite being an active donor of the FSF.

That GNUutils-with-autocomplete is real trivial to write, but since it's already in fish, I see no need to right it. :smug: [In all seriousness, I agree with you re: standards. Plan 9's interface standards semi-addressed that. But le sigh such is life.]

<comment><USER5> Powershell's almost great. Things are way too verbose. No built-in stuff like curl or wget (yes, there's a simple webrequest thing and aliases, but they're clunky). In fact, it feels like everything in PS is clunky.

Just simple stuff like "time ./foo" becomes "Measure-Command {... }" and then it prints out 10 lines of the same measurement, in different units. And doesn't distinguish CPU time versus wall time.

All that adds up and makes PS crap for interactive work. As far as writing programs, PS is a much better programming language than bash.

And yes, I understand that using a bunch of 3 or 4-char names kills your global namespace. But judicious use really aids ergonomics.

<comment><USER4> Yeah, for things like that, I have a wrapper function and/or aliases which get loaded with PowerShell. The over-verbosity I'd imagine really helps the "click next-get cheques" guys who are a little intimidated by the command-line. (I on the otherhand bleed Hayes 9600 baud and VT220 green cold cathode.). 'ps aux' wouldn't really cut it. Just like one customizes their bash, fish, zsh or whatever shell, you customize your PS shell with modules (the Powershell Community Extensions (PSCX)) and other such things (SQL Server integration with Powershell? Yes please!).

So you effectively can do t foo, which your alias to a wrapper script around Measure-Command and get the same effect. But, wait, you also want to log the outputs, just to keep track of the progress as you refine the memory allocation on my_malloc.cc. Pop into ISE[1] stock with Windows 8+ (or your favorite Powershell editor) add a few lines and now you can have a log that associates each revision with it's performance. Keep it open like you would your editor and your .bashrc or .zshrc or whatnot.

The great thing about that is I only have to write the verbose command _once_ and it's entirely clear what that command does. I can share it with _anyone_ and they can run it, assuming they have .NET 4 or higher. They know immediately what it does.

RE: Other software - All the unix utils (grep, awk, etc) are in a downloadable "Gow". Windows has a package manager "chocolatey" which is basically like the apt repos. All the software is vetted. Heavily. They run every binary through VirusTotal which is 57 engines from the enterprise Sophos type stuff to the less-good-ones.

I've run into one bug in 18 months (multiple python installs 2.7.1 / 3.4.x + the env var of PythonHome conflicting references. I'm sure there's a solution but I don't care enough about python to research it).

[1] [https://i.imgur.com/dXmT2MX.png](https://i.imgur.com/dXmT2MX.png)

<comment><USER6> Hayes 9600 baud? VT220? Geez, kids these days...setting your (directly attached) ADM-3s to 1200 bps in order to smooth over the task-switching jerkiness of your PDP-11 ;-)

Back to PowersShell. When I first looked at it, it seemed like just the right answer, but on closer inspection...not so much. Being able to customise: yes. Having to customise right out of the gate to get an even barely usable experience: not so much.

It is obvious that the task is difficult, but PowerShell shows many interesting direction and some ways to not solve it.

</comment></comment></comment></comment></comment></comment><comment><USER7> My number-one wish for a NGS:

Undo!

Take, for example, rm. The hoops we have to jump through when accidentally rm'ing a file are ridiculous [1]. But in most cases (smallish, non-secret files), rm should be trivially undoable. Windows gets this right: By default, files are not deleted, but moved to trash. If there is not enough space in trash, Windows warns you. Or, if you really want to delete a file instead of moving it to trash, you can press SHIFT+DELETE, in which case Windows will also warn you that it can't be undone. (What is missing in Windows is a "nuke" option that overwrites the old bits with random data, for those rare cases where a file must be purged from the system completely.) But in most cases, after deleting a file, you can simply press CTRL+Z to get it back.

It is possible to make rm behave like that in Linux [2], but in a NGS, this should be the default behaviour (in my view), with "delete" for really deleting (unlinking) a file, and "nuke" for completely distroying a file, as seperate commands.

Undo is hard. Most programs are on their third, fourth, or even higher release before getting it right. (Mathematica 10 is stil trying to get there...) But I think we should try harder to solve the undo-problem with respect to file- system interactions, or with respect to system-settings, in Linux.

[1]: [http://unix.stackexchange.com/questions/10883/where-do- files...](http://unix.stackexchange.com/questions/10883/where-do-files-go- when-the-rm-command-is-issued)

[2]: [http://unix.stackexchange.com/questions/42757/make-rm- move-t...](http://unix.stackexchange.com/questions/42757/make-rm-move-to- trash)

<comment><USER8> >Windows gets this right: By default, files are not deleted, but moved to trash.

The del or Remove-Item commands also permanently delete the file, just like rm. The "Windows" behavior you're talking about is the behavior of the graphical shell Explorer, which is also present in Gnome and KDE. There's nothing specific to Windows here.

<comment><USER7> You are right, I forgot about Gnome and KDE. I tend to use classic shells on Linux, and the graphical shell on Windows, so I made a wrong generalization. It's probably more accurate to say that "undo" of simple operations (rm, mv) is something graphical shells get right.

But why are classic shells shipped without even the simplest "undo" features? We can probably all tell stories-from-the-trenches of how we accidentally did something aweful by typing the wrong command. Sometimes, it's hosing the network configuration of a remote machine, which is not something where "undo" would help you. However, in my experience, most cases involve doing something foolish with rm or mv, where "undo" would be tremendously helpful. I guess the main reason why I don't use the text shells of Windows is that Windows explorer gives me Ctrl+Z, which is saving my behind approximately once per year.

As a final thought, all shells (graphical or not) should expand the undo- features beyond rm and mv. For example, if I change system settings (or even Application settings?) and am not happy, I would love to be able to simply "undo" them, without trying to remember what the previous setting was. I realize that this is an incredibly hard problem, and that it is unlikely to be solved in an evolutionary step of the existing shells. That's why hearing about NGS got me so excited.

<comment><USER9> > _But why are classic shells shipped without even the simplest "undo" > features?_

This question is assuming an untrue premise. There are Windows command interpreters that integrate DEL and RD with the Recycle Bin.

* [https://jpsoft.com./help/del.htm#r](https://jpsoft.com./help/del.htm#r)

* [https://jpsoft.com./help/del.htm#k](https://jpsoft.com./help/del.htm#k)

* [https://jpsoft.com./help/rd.htm#r](https://jpsoft.com./help/rd.htm#r)

* [https://jpsoft.com./help/rd.htm#k](https://jpsoft.com./help/rd.htm#k)

</comment></comment></comment></comment><comment><USER10> A shell is an application that provides system interaction to users.

> _What I see is a void. There is no good language for system tasks (and no > good shell). What 's near this void is outdated shells on one hand and > generic (non-DSL) programming languages on the other. Both are being > (ab)used for system tasks._

Aside from the, in my opinion, abhorrent word "outdated" (why are old things considered _bad_ just because of their age?), the comment about there being "no good shell" is something I disagree with very much. Personally I'm really fond of zsh and its manual pages are a treasure trove. But, lest this digress into a flamewar about shells or into a non-productive discussion about preferences, the point I would rather make is that the author provides a different thing than, as it seems to me, qualifies as a shell.

For example, the open issue mentioned in the README is:

 _Open issue: how to deal with a command that requires interaction._

As a Linux system administrator I am happy with the tools I have, and initiatives such as this seem to digress into the realm of the programmer. Sysadmins and programmers (a.k.a. developers - though I'd consider myself a developer too but not a programmer) tend to have very different perspectives about how to get an application onto the environment on which it runs, within the greater system of servers and networks.

In that sense, Docker and such mostly seem to get a preferential treatment from programmers, while sysadmins (again, as it seems to me) tend to dislike these kinds of abstractions. And I often get the impression that developers haven't got as much appreciation for sysadmins and what they do, as vice versa, but this could be false, or even more likely is that this is true for some and false for other cases. OMMV.

NGS might be a very useful project, I'm not at all negative about the project itself. It just seems more useful to programmers than to people like me who enjoy nothing more than to interact with their command line interfaces a.k.a. shells.

<comment><USER11> I'm suprised you can't think of problems you currently have with shells. Here is a few of mine:

* Once I've started a program, and easy way of sending it to the background if it is taking a while, which sends it's output to some buffer I can refer to later, rather than continuing to spew it all over the screen.

* While we are at it, stop spewing the output of multiple programs over the screen, under any circumstances.

* Have some simple, easy to follow rules which let me work on files that have spaces in their names, without having to remember the various commands with various special cases (like -print0).

<comment><USER12> issue 1) sounds like you miss nohup, sreen or tmux in front of that long running program.

issue 2) usually I don't have one terminal session with multiple programs doing output at the same time, this solves this issue.

Just use a new xterm, a new terminal tab, a new screen tab for programs that are going to produce output and stay running.

issue 3) I think you refer to files with other special characters, because spaces on filenames do not need -print0 at all, simply proper quoting in the code will do.

Regarding issue 3, there is a lot of caveats when coding shell; even file names starting with a dash (-) which are interpreted as options by tools external to the shell (which fortunately support a double dash (--) to stop processing parameters).

<comment><USER13> The point of issue 1 is that sometimes you don't know that the program will run for a long time. So a way to send a program into the background while it is already running, would be nice.

<comment><USER12> 'Ctrl + z', 'bg' and 'fg' are for that.

<comment><USER11> Except, now you are back to my original problem -- the output of the program will continue to spew all over my terminal.

<comment><USER12> Well, if you work always in tmux/screen (a recommended practice for operations, that I did import to my daily shell activity) you don't need job control.

When there is a "surprisingly slow" command, then just press the shortcut for a new screen session.

Will get alerted in the status bar when the slow command finishes.

Output of each command will be in it's own screen session (not mixed).

That Ctrl + z response was no for issue1, but for the wishes of the second sentence of @hibbelig.

<comment><USER13> I meant to include the part of capturing the output -- the part that Ctrl+Z does not do.

Opening a new screen/tmux session is a cool idea, but the new session doesn't inherit the state from the already running one, I guess. (At least in screen, not sure about tmux.) By "state" I mean the shell history, the current working directory, the (environment) variables.

Also, say that long running command runs five minutes, and after one minute you create a new session. Then after four more minutes you now have two sessions, both ready to accept input. Which one do you use to continue working? How do you know which one to close?

<comment><USER12> My screen respects the current working directory for new sessions.

My history is configured to write at every prompt redraw and to don't miss commands.

With vanilla history and prompt command settings, history will be separated.

But as this is a common problem, and not only with screen, also with multiple xterms and IDE's shells, and... also is a problem that history may miss lines by default...

And as it's a common problem, there are settings to fix that, configure the history merge strategy to your taste and do not miss history lines, because you did close a xterm, or you did open a new screen sessions.

Curiously, those settings are even documented upstream.

Session variables? I expect the ones that could be loaded by login executing bash -l...

If I did export something after that, then maybe I simply need to export it again in a new session, but really in 20 years never was in this situation I think... (do not wait to a command, continue with other commands, and need a environment variable not initialized by default between both sessions....). If I was in that situation... was so easy to fix that I don't even remember.

Which one to close? the one I prefer randomly, probably by focus, or probably the highest screen id. As history is merged, I can close any or even both.

<comment><USER13> Thank you for all these great ideas. Yes, I totally forgot about settings to merge history.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> For me a next generation UNIX shell needs to catch up with what REPL environment in Lisp Machines, Interlisp-D, Mesa/Cedar, Smalltalk, Oberon(-2), AOS features and capabilities.

For the young HNers, think having something like Swift Playgrounds or IPython as your shell, while having full access to the OS API without relying on external programming languages.

Otherwise the _next generation_ prefix isn't worth mentioning.

<comment><USER15> And arguably you'd have to call it last-generation as well, if you recall how long ago those innovations happened but never made it into mainstream. That would label current shells as dark age of tty :). I still cannot accept the fact that we use tty emulators.

<comment><USER14> For me PowerShell feels a bit more closer to that model, but it is still text based, no inline graphics or data structures output, and the syntax could surely be improved.

<comment><USER16> PowerShell actually does have data structures, and that's my favorite part of it. Pipe a directory listing as an object instead of text so you can access properties directly instead of parsing text!

<comment><USER14> No,I mean displaying them inline in the REPL and allowing you to interact with them.

<comment><USER17> Well, that's an issue with the REPL, not the design of PowerShell. No reason you couldn't make one that does this.

<comment><USER14> Sure, I do like it much more than any UNIX alternative and it is the only widespread shell that is closer to the experiences I was referring to.

But that REPL could be improved, that is what I mean.

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> Having read through the readme, I think some of the issues outlined could be solved by having a cell-based model like jupyter/ipython.

Basically a command (input) and its corresponding output are tied together as a "cell". The UI could be very like the ipython notebook, where you have a text box for command input and then above it you have a chronological list view of cells. You would also have a good keyboard-shortcut language for navigating back and forward in the cell history, so you could, say, go back and focus a cell which has been running for a while and is now prompting for input.

(Edit: imagine a key sequence like `Alt-b, Alt-b, Ctrl-Enter` meaning "go back two cells and give text focus to that cells input field.". In reality you'd probably want a command language that's more vim-like.)

The cell model would also allow you to truncate output, minimize or maximise the cell display, and a bunch of other UI tricks I can barely think of right now.

Basically each cell would be a little parallel shell of it's own.

If this sounds even remotely compelling, I wouldn't mind writing up a more formal proposal and submitting it as an issue on the repo.

</comment><comment><USER19> There are lots of mixed-up goals here that I think might be better served broken out into multiple projects:

1) Terminal UI improvements 2) Interactive shell UI improvements 3) Shell scripting language improvements 4) Userspace utility improvements

Tackling all of these together may well be possible, but it will likely limit the potential impact of any improvements you are able to make. IMO, it's easier to move the status quo with incremental improvements, not wholesale re- imaginings of how the entire text-based Unix user interface works.

Ultimately, the most dangerous thing to mess with is the language itself. The strongly-typed Python-lite described in the linked man pages is not going to replace sh/bash for simple scripts, sorry. For most shell-scripting needs that sort of thing is wayy overkill. Sure Bash is ugly, but ultimately there's no way to harmonize quick-and-dirty command-line compatibility with an elegant scripting language syntax.

An alternative approach here would just be to expand your thought process a bit and don't get too worked up about Bash itself. Pipelines and new tools can solve all your problems if you're willing to think about them in a different way. `jq` is an amazing pipe-friendly JSON munger that is now just as essential to my CLI toolbox as `awk` and `sed` ever were. It solves your structured-data and typing complaints without interfering with Bash one way or another.

<comment><USER20> > The strongly-typed Python-lite described in the linked man pages

It's not strongly typed and types annotations can be left out in many places:

mylist.map(F(elt) "my $elt")

elt type is not specified.

The command syntax $(...) will cover some of the simple scripting needs. Please provide specific code examples (probably in bash) that you think will look bad.

> `jq` is an amazing

It is but in my opinion much less convenient than built-in support for data structures.

</comment></comment><comment><USER21> Looks quite interesting! Some feedback:

Yes, a new paradigm for interacting with text commands would be wonderful. But what would that look like?

One strong advantage of the current system is that the input matches the interface. Everything is text, so it all can be typed with the keyboard. But if this shell "displays structured results as real f __ing structures (YAML, JSON, ...) ", that may not be true. If the shell spits out a table, is it a CSV table? A YAML / JSON nested array? How is the user supposed to edit it? The interface isn't clear, and any layers at all are going to take some thought to be able to compose naturally with other tools. (The author addresses part of this with "All operations made via a UI, including mouse operations in GUI must have and display textual representation, allowing to copy / paste / save to a file / send to friend.")

Another thought: from the proposal in the README, it isn't super clear which tasks the author feels the shell ought to handle versus which tasks should be handled by some other toolkit. For example, the "Manage multiple servers at once" subsystem is handled by other devops tools like Ansible or Chef at the "deploy an application" layer and tools like Tmux or 'clusterssh' at the "send input to multiple processes in many screens at once" layer. Another example: the author proposes "Actions on objects that are on screen. Think right click / context menu.", but since these actions _must_ require cooperation by the program being invoked, it's not clear whether this serves the purpose better than simply wrapping that program's operations in some GUI toolkit.

This could be pretty interesting, but I wish the author would formalize some of this thinking into a concrete standard. Having too big of a vision without some set boundaries seems to be hurting the focus of this promising project.

<comment><USER22> > "One strong advantage of the current system is that the input matches the > interface. Everything is text, so it all can be typed with the keyboard. But > if this shell "displays structured results as real fing structures (YAML, > JSON, ...)", that may not be true. If the shell spits out a table, is it a > CSV table? A YAML / JSON nested array? How is the user supposed to edit it? > The interface isn't clear, and any layers at all are going to take some > thought to be able to compose naturally with other tools. (The author > addresses part of this with "All operations made via a UI, including mouse > operations in GUI must have and display textual representation, allowing to > copy / paste / save to a file / send to friend.")"

In PowerShell, all data is stored as .NET objects. Using this object-oriented approach enables the sort of flexibility I believe you're looking for. Perhaps something similar could be developed for Linux. There has been some activity in this area:

[https://github.com/Pash-Project/Pash](https://github.com/Pash-Project/Pash)

[https://blogs.msdn.microsoft.com/powershell/2015/05/05/power...](https://blogs.msdn.microsoft.com/powershell/2015/05/05/powershell- dsc-for-linux-is-now-available/)

[http://www.forbes.com/sites/justinwarren/2016/03/08/is- micro...](http://www.forbes.com/sites/justinwarren/2016/03/08/is-microsoft- about-to-bring-powershell-to-linux/#663910e8528b)

</comment></comment><comment><USER23> Lots of assertions about how "bad" our current shells are, but no substantiation. I'm a developer, and I know just enough shell to write a simple deploy script or two, but reading this, I'm not convinced that what we really need is new shells and scripting languages.

<comment><USER20> Simple example: using current shells it is not convenient to work with API call results which are structured data. Yes, there is jq but if the shell had data structures it would be much better, wouldn't it?

<comment><USER24> On UNIX, the "API" is basically that everything is a file and programs are written to handle text streams. After all these years, the shell is still perfect for this.

It sounds like you want create a new language and shell in order to have something similar to Windows PowerShell which interacts .NET objects using its API. This does not fit into the Unix "API" described above. This isn't a "Next Generation UNIX Shell" but an alternative shell that suits a certain group of users who don't really understand UNIX.

<comment><USER25> That's great, but how much data do you work with, day-to-day, that is best represented as text streams? For me, the answer is "virtually none". Heck, most of the stuff I work with, day-to-day, _can 't even be represented meaningfully in a text stream_. (Editing video, for example.)

<comment><USER24> For me, the answer is "plenty", but that's neither here or there. Everyone has their own use case and I daren't say yours isn't valid.

Video editing tends to done in applications, of course that's not to say video data can't already be piped. I once set up a screencast using gstreamer to convert /dev/video to an HTML 5 compatible video format which I then redirected to a named pipe which could then be opened from a HTML file page in a web browser. The UNIX shell is already very powerful. You haven't stated what it is you want to do with video editing that is either difficult or not currently possible but would be possible with this new shell, so I'm not sure that I really understand the point that you are trying to make.

There is nothing wrong with creating an alternative shell. I can see the need for something like this. PowerShell for example works very well. My main gripe with this project is that the author has named it "Next generation UNIX shell" which suggests that it is intended to be a replacement rather than an alternative. In my humble opinion, it tosses the simplicity out of the window that makes UNIX, UNIX.

To quote Dennis Ritchie, "UNIX is simple. It just takes a genius to understand its simplicity." I'm no genius, but I get it.

</comment></comment></comment></comment></comment><comment><USER26> I don't think there's enough that needs fixing in the current shells/terminals that require a new paradigm at the moment. These things seem to come and go without much adoption.

Sorry, bit negative of me - it's awesome that people are trying.

</comment><comment><USER27> Just because something has been around for a long time it doesn't mean that it's outdated. On the contrary, it means that it's stood the test of time, which is usually a sign of a good design.

<comment><USER20> Sorry, by outdated I meant not a good fit for today's problems.

<comment><USER28> Personally, I don't see how today's problems are that much different. I agree we should _always_ be looking for better solutions, but IMO, it seems better to adjust our current tools than to rewrite them.

</comment></comment></comment><comment><USER29> Something I would LOVE to see (not only in a shell but in all tools) is some kind of "project mode".

\- In Chrome/Firefox I'd like to have a mode for recreational browsing, one for research of webdesign and one for fitness/health stuff. This basically means that I want to click at a browser window and say "This is now my fitness window. Please remember all the open tabs". And then there is a list of open sesions/projects where I can switch between those views/instances. I'd like to be able to close my fitness-window (without losing my fitness tabs) and then re-open the same fitness-window on the next day.

\- For Dolphin/other_filemanager I'd like to see a "normal" mode for everyday browsing, a mode with large icons for sorting pictures and some mode for working with Python scripts in which the nautilus terminal is always open

\- for Sublime I want a scratch window where I open and edit random small files, one for my html coding and one for my Python coding

Currently for almost every program we only either have one "session" or some really specific project settings (like Visual Studio) but I'd like to see something in between.

For example I have a lot of HTML files open in Sublime and I need to edit some unrelated config file. If I just open this config file it will open in the same window as the html files. What I'd like to have is a way to say via comment line or context menu "open this file in scratch pad mode".

The same for Dolphin. If I have one instance of Dolphin open for picture management with large icons and I have to do some Python file editing I'd like to have a simple way of saying "Open Dolphin in python mode".

Or sometimes I have a random link. I want to open that link in my "random browsing" instance of Chrome and not in the window which has currently all my fitness tabs open.

And the same is true for video players, music player, ebook programs, ...

<comment><USER30> > \- In Chrome/Firefox I'd like to have a mode for recreational browsing, one > for research of webdesign and one for fitness/health stuff. This basically > means that I want to click at a browser window and say "This is now my > fitness window. Please remember all the open tabs". And then there is a list > of open sesions/projects where I can switch between those views/instances. > I'd like to be able to close my fitness-window (without losing my fitness > tabs) and then re-open the same fitness-window on the next day.

Sounds like you're asking for 'Tab Groups'. It used to be a feature built into Firefox, but recently got removed due to lack of use, it is however still available as an add-on (mostly using the existing code that was removed from Firefox itself afaik):

[https://addons.mozilla.org/en-US/firefox/addon/tab-groups- pa...](https://addons.mozilla.org/en-US/firefox/addon/tab-groups-panorama/)

<comment><USER29> I used to love and use Tab Groups but it was always amazingly slow on my PC (old-ish Celeron 2.6 Ghz)

</comment></comment></comment><comment><USER31> > The problem with outdated shells looks pretty clear: they were made with one > kind of tasks in mind but are used for other, bigger and more complex tasks. > Such scripts usually look as a fight against the language and working around > it much more than using it to solve the problem.

Mind you,

> Create a shell (in that language) that is up to date with today's tasks - > cloud, remote execution on a group of hosts.

I'd rather create another DSL/tool to solve it.

> Two languages actually.

> Current-shells-like but simplified (called "commands"), $(...) syntax

> Scripting language, "normal" programming language (called "code"), {...} > syntax

Good luck.

> The scripts that I've seen (and written in Python and Ruby) look too verbose > and show unnecessary effort. Such scripts do not look an optimal solution > (at the very least).

Did you check scsh? (I don't use it.) [http://scsh.net/docu/html/man- Z-H-3.html](http://scsh.net/docu/html/man-Z-H-3.html)

<comment><USER32> The QNX shell could easily do remote execution. I worked at a company in the mid-90s (porting Unix software to QNX). My machine had a modem on it, and my boss (the owner of the company) would use it from his computer to dial out--- all he had to do was reference the modem device on my computer at his command line.

In fact, you could run a program on a local machine referencing a file on a second machine, pipe the output to a program on a third machine and have that redirect the output to a file on a fourth machine, all from the command line. I don't recall the exact syntax, but it was something like:

        cat @2/path/to/large/file | @3/bin/grep 'foo' >@4/tmp/output

(Individual hosts were numbered on a QNX ethernet based network, but the default permmissions were Unix like). All of this was a consequence of the message-based QNX operating system (whether messages were delivered locally or remotely was invisible to programs) but I don't see why something like can't be done today.

<comment><USER33> This is a quite neat example, but it looks like the QNX shell mixed several concerns about how do you connect to these machines, how do you secure the communication, etc.

        $ ssh @2 "cat /path/to/large/file" | ssh @3 "/bin/grep 'foo'" | ssh @4 "cat >/tmp/output"

is rather clunky, but separates those concerns well.

<comment><USER32> Sorry about not getting back sooner (returning from vacation) but the QNX network message passing ran over Ethernet, not IP, so it only worked (to my knowledge) over a local segment. Given that it was transparent to user processes, it could be argued that security could be added at that layer (two of the seven layer OSI model).

</comment></comment></comment></comment><comment><USER20> Thanks for your input and GitHub stars! You are all very welcome to open GitHub issues with your suggestions.

I'm looking for developers to join the project. There is a lot of work to do :)

Ilya Sher, the author.

</comment><comment><USER34> Actually rc was the next generation Unix shell.

(Personally, I use ksh, which, while as bloated as bash, is bloated in more useful ways, and not so gratuitously divergent from plain sh.)

</comment><comment><USER35> If processes were referentially transparent functions, the shell would be wicked fast as it can run commands speculatively as you type them and discard the side effects if you backspace and memorize the results. Along with a zillion other game changer benefits like determinism. Built in perfect auditing. Rewind and restore processes to past states. That's what we should be striving for. But it's a lot harder.

</comment><comment><USER36> The first few bullet points (regarding job control / status / blocking) sound interesting and useful for anyone. I think it would be cool to have a shell with some sort of visual job control system and an easy way to background anything that was taking significant time. Maybe that wouldn't be as deeply integrated as the system the author is describing, but it would probably be easier to implement and less of a change from a standard shell. These days I hardly ever suspend a process and continue it in the background because it's easier to spawn a new shell, but if that workflow were streamlined... maybe I wouldn't need a dozen shells open all the time.

As for the rest, I dunno. Neat, but complex solutions like this make me pause. Maybe instead of trying to solve this problem, we should instead try to not have this problem. That is, if your tools require this much of your shell, maybe the tools are the problem and not the shell?

</comment><comment><USER37> IMHO the world does not need another Shell language. Please not... it's even sometimes complicated with ZSH & FISH today. A shell which behaves totally different will get me totally different problems than nowadays... no thanks. I know my "enemy and friend" Bash and it's a good thing I get it nearly everywhere.

</comment><comment><USER38> My 2 tinfoil hats: If they can't have your kernel, they try to get your shell...

To me, i really do not see the points listed to be missing. For instance my shell script for remote execution on multiple hosts needs somewhere around ten lines of code and a peer list. I would never outsource this to an external entity. Especially today.

</comment><comment><USER39> Actually... bash is a pretty solid language since version 4, just no one takes time to learn it.

<comment><USER40> Might you elaborate on what version 4 does new/differently?

<comment><USER41> associative arrays are one of the biggest v4 advantages

</comment></comment></comment><comment><USER42> The irony...

> Next generation UNIX shell. See the man page.

</comment><comment><USER43> I think an OOPish DSL as a shell is pretty wrong[0], to be honest. Most of the time in UNIX what you're doing is chaining commands or automating. So perhaps what's needed is a DSL with a more functional, stream-based approach. Something along the lines of:

> map `rm -rf ` (grep "*.tex" (ls))

[0]: I haven't had much experience with FOOP, however.

</comment><comment><USER44> Use a general-purpose language with macro's or DSL's. Racket and Rebol are older ones with RED language being designed partly to do what article describes.

[https://en.wikipedia.org/wiki/Red_%28programming_language%29](https://en.wikipedia.org/wiki/Red_%28programming_language%29)

</comment><comment><USER45> If you're into Scala, Haoyi Li has a great video about his (similary) Ammonite project

[https://www.youtube.com/watch?v=dP5tkmWAhjg](https://www.youtube.com/watch?v=dP5tkmWAhjg)

[http://www.lihaoyi.com/Ammonite/](http://www.lihaoyi.com/Ammonite/)

</comment><comment><USER46> I suppose all of the behavior should be highly customizable. It would be nice if plugins could be written in any language. For example, I expect special CLI editor extensions for editing JSON input to programs (with syntax highlighting if desired). Also, I expect specific key-bindings (for e.g. vi/emacs modes) to be pluggable.

<comment><USER20> I encourage you and others to open issues or make a pull request with updated README

</comment></comment><comment><USER47> The github page links to a screencast which I found more helpful than the github writeup itself:

[https://www.youtube.com/watch?v=T5Bpu4thVNo](https://www.youtube.com/watch?v=T5Bpu4thVNo)

</comment><comment><USER48> But why nodejs?? There are a lots better languages to base this off of.

<comment><USER49> Probably because JavaScript is the worlds most popular programming language, it's portable, has the largest package manager, supports the shell's non blocking requirement, and the current version (ES6) has a better stdlib than previous versions.

<comment><USER50> You're wrong on about three of those statements, but note that the same hand wave could have been made for Perl ten years ago. That would've been a poor choice then for the same reason Javascript is a poor choice now.

<comment><USER49> > You're wrong on about three of those statements

OK. Do you have any supporting arguments? "You're wrong" doesn't contribute anything.

> note that the same hand wave

It's not a "hand wave". Those things are easily verifiable facts. You're new here, you might want to read:

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

<comment><USER50> Not new. Javascript is not the most popular language, does not have the largest "package manager" (nor standard library, nor package library which is what I think you mean) and more importantly it does not have the most programmers specializing in the problem domain at hand -- shell functions. Moreover the referenced toolset _doesn 't even use Javascript_! You merely jumped in blind to promote your favorite tool. Also if you want to play HN-by- the-book then you should refute my argument why Javascript shell scripting in 2016 from a cold start is somehow better than Perl shell scripting in 2000 given its lead back then.

<comment><USER49> > Javascript is not the most popular language

> does not have the largest package library, which is what I think you mean.

Yes, you've said that before. Do you have any supporting arguments?

I'm basing that opinion on:

1\. JS is #1 on modulecount and #2 on libraries.io, the two places that track the size of package repositories.

2\. JS continually coming up as the #1 or #2 most popular language on StackOverflow eg [http://www.r-bloggers.com/the-most-popular-programming- langu...](http://www.r-bloggers.com/the-most-popular-programming-languages-on- stackoverflow/)

Happy to talk about Perl once this becomes a dialog rather than you telling me I'm wrong without the courtesy of explaining why.

<comment><USER50> And the most popular girl in my high school can't ride a motorcyle. I took her to prom but I'm not inviting her on my next cross-country ride. What's your point?

[https://en.wikipedia.org/wiki/Measuring_programming_language...](https://en.wikipedia.org/wiki/Measuring_programming_language_popularity)

Regardless you don't pick a toolset based on popularity. You choose it based on capability. 100,000 front-end HTML developers asking the same "how do I regex?" question on StackOverflow 10,000 times doesn't pre-qualify an ecosystem as the perfect tool for shell automation.

And at this point you're just trying to save face after you jumped in to explain why it's such a great idea that this project uses Javascript. It doesn't. I'm moving on and suggest you do the same.

<comment><USER49> My point is that while you keep saying something is wrong, the evidence shows otherwise.

I'm pretty sure you're already aware of that. Your account is new, perhaps you've been here before but you don't seem very capable of participating in technical discussions. I'm going to end this conversion for obvious reasons.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER51> There've been many attempts and no web-based shell is the next generation - only the next toy. A replacement of Bash, Zsh, and Fish is needed, it just won't be a web-based toy!

</comment><comment><USER52> Curious if anyone here has adopted the shell mode of iPython as their routine shell (or something similar). Is it a good idea? Experiences?

</comment><comment><USER53> So, this project starts about shell, then I see it also aims to implement full-blown terminal emulator and a lot of new very ambitious features, and then it invites terminal-based apps to use new capabilities of it, so it would be best usable only if the whole ecosystem of compatible apps appear.

Unfortulately, I'm pessimistic.

Also, would like to comment on project's README. Not meaning to be harsh.

> The shells never caught up.

Wrong. To prove this, it is enought to see that almost none of "features" is new in comparsion with traditional terminals.

> Not to block, allow typing next commands even if previous command(s) still > run(s).

Got a plenty of ways to handle that with shell. Backgrounding, GNU Screen, Tmux.

> Open issue: how to deal with a command that requires interaction.

Oh yeah, you've invented a thing and don't know how to use it with real-world apps. Happens.

> Provide good feedback. In GUI for example, this can be green / red icon

Enhanced setting of shell's "PS1" variable gives you good indication of exit code of last app (color + text + whatever, you may even use audio if you want). I'm using it for years.

> All operations made via a UI, including mouse operations in GUI must have > and display textual representation, allowing to copy / paste / save to a > file / send to friend.

Sure, why not, but all this is possible with shells. Both native consoles (with gpm) and X11 terminal apps, and also Tmux has its own possibilities to handle clipboard.

> Different UI modules must exist

Lots of people was playing around with shells via IRC or XMPP ages ago.

> Web

Good luck handling keystrokes with tricky keycodes, and preserving all other standard terminal features. BTW I thought this project aims another shell, but this sounds like requiring another terminal emulator. I'd be glad to hear we have powerful web-based terminal emulator, but this feels very laborous.

> allow multiple users to collaborate

Screen/Tmux.

> some rw, some ro

Seems lacking in tmux at the moment, but possible to implement on its own, without reinventing everything else.

> Most of the data dealt with is tables. List of files, list of instances in a > cloud, list of load balancers. Amazing that none of current shell tools (I > heard of) don't treat the data as such

It is discouraged to parse textual output of shell programs unless app clearly guarantees unchanging parsable/consumable format (with specific options you use). Quite often there's another, more reliable way to mine information than parsing of output of general-purpose program.

> Allow editing it and saving to file

some_program | vim -

Then, in editor, edit and save. Done. If you add too many specific usecases into the core, you end up with bloated interface.

<comment><USER54> "So, this project starts about shell, then I see it also aims to implement full-blown terminal emulator and a lot of new very ambitious features, and then it invites terminal-based apps to use new capabilities of it, so it would be best usable only if the whole ecosystem of compatible apps appear."

This is actually my only objection and the only feedback I'd make to the author. Contra some of the other posters here, I fully agree shell is a mess and that the basic root cause of the mess is that you can not straddle interactive use and programmatic use with one language. But something a bit smaller needs to be bit off.

I'd also suggest that most shells have already got the interactive use case sufficiently covered and that the low-hanging fruit is in the command case. Perl is perhaps the best language that functions as a programming-shell replacement, but using it for a while reveals it still has many significant issues in that use case. Even with modules, it pipes surprisingly poorly. It tends to make stream processing harder than it needs to be, unless "one line at a time" works for you. It's got a lot of nasty syntax that is arguably optimized for big program use cases that doesn't make sense when replacing shell scripts. When being used for shell programming, it basically shares C's abject failures when it comes to error handling, making it range between bizarrely difficult (I have to left-shift the result of system to get the actual exit code?) to almost-impossible-to-remember (backticks) to get errors properly handled. It has no concurrency story or any particular "run on multiple targets" ability (though I confess I don't know what that looks like necessarily; in my head it rather becomes puppet or ansible fairly quickly).

There's room here, but it's going to be an uphill battle.

<comment><USER9> > _[...] shell is a mess and [...] the basic root cause of the mess is that > you can not straddle interactive use and programmatic use with one > language._

Note that some of the world has already taken this notion on board long since. About a decade ago, Debian Linux and Ubuntu Linux swapped out /bin/sh so that it was no longer the Bourne Again shell. Nowadays, as a result of this, one regularly finds Linux systems where programmatic shell scripts are interpreted by something like the Debian Almquist or Debian Policy-Ordinary (posh) shells and interactive login session shell work is the domain of the Bourne Again, Korn, Z, or other shells.

And of course, having a different "better" shell for interactive use was the reported rationale for the C shell.

</comment></comment></comment><comment><USER48> But why nodejs?? There are a lots better languages to base this off ove.

</comment><comment><USER55> Because lol, standards.

</comment><comment><USER56> [WARNING, RANTY]

This is a blue-sky project. Completely new, with no legacy dependencies.

AND YET THE DEVELOPER CHOSE TO WRITE IT IN C. WHY FOR THE LOVE OF GOD, WHY?

Could someone explain this to me? Is it developer hubris, believing in one's own infallibility that a single exploitable stack frame or buffer overflow couldn't possibly happen "on my watch"?

If you need a native binary, your options are endless. Rust, Go, Haskell, hell, even C++ with smart pointers and runtime bounds-checking would be a step up.

Please, someone educate me on why people still choose to write inevitably- vulnerable software in 2016, when there is no legacy reason to do so.

<comment><USER52> Do you think it's a bad idea that git and the Linux kernel are written in C? Is the possibility of a buffer overflow important in a program that's not processing input from random people on the internet?

<comment><USER56> No, because they are both legacy software. I understand momentum in codebases - that's why I'm reserving my vitriol for fresh bluesky projects like this one.

As for exploitability, privilege escalation and shellcode injection is still very much a thing, internet-facing or not.

<comment><USER52> Git started in 2005. I'm sure Torvalds knew all about buffer overflows then, but decided to use C. You seem to think this is a crazy decision.

<comment><USER57> > Git started in 2005. I'm sure Torvalds knew all about buffer overflows then, > but decided to use C. You seem to think this is a crazy decision.

Well is it? Will it be if Linus isn't maintaining it?

<comment><USER52> Linus Torvalds has not been the git maintainer for years.

</comment></comment></comment></comment></comment></comment><comment><USER58> What is this intended on fixing?

I don't think the solution to anything is to make the shell more user- friendly. The only solution is to make the graphical user-interface more user friendly and feature full.

The only time it should be acceptable to be forced to use a shell, in my opinion, is if you are swapping out your desktop environment.

Until that happens, Windows and OS X will rule the desktop and PC market.

I'm fairly certain that Linux-based distributions will win out in the end if we can overcome this clingy gravitation to a command line. It's already happening already. Android is already winning against all of the major phone platforms and it's not because of it's award winning terminal emulator.

<comment><USER59> > The only solution is to make the graphical user-interface more user friendly > and feature full.

There's only one feature that matters here, really: composability. Provide an environment in which I can compose simple tools into complicated workflows I can fling data through, and we might have a winner.

> The only time it should be acceptable to be forced to use a shell, in my > opinion, is if you are swapping out your desktop environment.

Why should that be true? It's not at all obvious to me. I have yet to see a GUI that lets you express something like `grep '^127' /etc/hosts | awk '{print $2}'` in any sane fashion. The closest you get is something like LabView, but that's counted out here because it's a general purpose(ish) language.

If your response is that this type of task is artificially skewed towards a text-based, shell-centred environment, then you don't have the type of problem that this shell is intended to fix.

<comment><USER58> > I have yet to see a GUI that lets you express something like `grep '^127' > /etc/hosts | awk '{print $2}'` in any sane fashion.

I think we are in a very interesting time in computer science history where he have a huge slew of technology that solves a large set of problems that no one wants to exploit.

I could easily see an "assistant" type window being created in a desktop UI. Since we don't need a "windows" key in the linux world, I'd assume that would be used.

My ideal system would allow me to go into a text document, click the windows key, and say "grab me every line from /etc/hosts that starts with 127"

When the job would be completed, I'd see a check mark or something and the result would either be pasted to my cursor or, if my cursor wasn't in a text box, copied into my clipboard or something.

While this might sound like magical science fiction, it isn't. Neural networks, NLP, and HCI fields are doing some amazing things. The only problem is these are harder to implement then a simple terminal and pipe.

That is a sane way of interacting with a system that is user friendly.

In the same way, it could also handle other complex things. IE: "open my browser", "open the Internet", "list all the things connecting to the Internet", "open the last document I was editing in my text editor"

This is doable, albeit extremely difficult to implement well, but doable.

<comment><USER59> I think you might have missed the subtlety here. The interesting bit isn't `grep '^127' /etc/hosts`. It's `|`. There are umpteen ways to launch individual applications, but nobody's yet come up with quite such a flexible, simple and expressive way of getting them to communicate as streams of text.</comment></comment></comment></comment>


Some frustrated publishers are sitting out Google's GDPR meetings - <AUTHOR> https://digiday.com/media/no-one-thinks-good-idea-frustrated-publishers-sitting-googles-gdpr-meetings/ <comment><USER2> Judging by the ripples it causes, it feels like GDPR is a well done piece of legislation that will actually destroy some of the most invasive business models.

Google should tread carefully there. It is the future of their cash cow that is at hand.

It is somehow comforting to see an elected body being able and willing to cause such a stir.

<comment><USER3> Hmm, I thought that too. I assumed that all banks, cell phone operators, etc. that I use would have to ask me for consent to sell my data, track me.

But that did not happen, they just send a note with all those GDPR information what they do with my data and that they have a good news for me: I don't have to do anything, as all my "agreements" are still valid without any action from my side. They haven't given me an option to give consent for, say, calling me, but don't give consent for tracking and profiling. Looks like this is ok, unless Orange got GDPR wrongly and wants to risk fines but I don't believe that.

One of the biggest Polish news portal (wp dot pl) has figure out the fantastic idea - they show a banner with a long, long text, that says at the end that if I close that banner, clicking on X button, I am automatically give them permission to track me and do virtually whatever they want with my data. If I don't agree for their terms and I don't close the banner (which is agreement as well) I am taken to "advanced settings" page that at the end gives me only one option - to agree for tracking and all the shady stuff they want to do with my data. It is impossible to enter their portal without agreeing for everything they want.

WP dot PL is a big business owned by a big German media company, so I guess they figured out everything correctly, apparently the regulation has a lot of loopholes and anyone with smart lawyers can overcome GDPR easily.

<comment><USER4> The "agree by closing this popup" tactic is, as far as I can tell, not allowed under GDPR. Here's hoping all the companies that do that get slapped with a fine.

<comment><USER5> This forever popup unless you accept should run afoul of the language in GDPR that forbids the degradation of a service if a user does not opt in.

</comment></comment></comment></comment><comment><USER6> FWIW, Google blatantly ignores the GDPR and continues to track all users from the European Economic Area unless they opt out. If you log out of Google, clear all Google cookies, and visit [https://adssettings.google.com/anonymous](https://adssettings.google.com/anonymous) from the EEA, you'll find that "Ads Personalization on Google Search" is enabled by default and that the default state of "Ads Personalization Across the Web" is indiscernible.

<comment><USER7> It is not illegal to track users only if they opt out, by citing legitimate interest as the ground for processing not consent. That is how all privacy policy generators and lawyers handle google analytics, facebook pixel, even self hosted solutions like piwik/matomo. We will need to sit out what legimitate interests really mean, but at least in germany there are some state privacy agencies that put forth this approach where you allow to opt out.

<comment><USER8> While I think it may be easy to argue that use of Matomo is legitimate for the purposes of improving your service (and as a corollary, this can legitimately be outsourced), I think it is a stretch to conclude that it is legitimate for the third party to assemble a dossier of an individual by tracking them across multiple sites for which analytics are outsourced to the third party.

This seems obvious since the third party is not going to expose details about the data subjects use of the other sites so it cannot be of legitimate interest to the primary controller. If they did share such data with the primary controller, the privacy violation is so egregious it cannot hope to pass a balancing test to be considered legitimate.

So while something like piwik may be allowed to be opt out, I think google may be treading on thin ice.

<comment><USER7> I agree, and Google is probably well aware that they tread on thin ice and they will probably fight their version of legimitate interst up to the European Court of Justice.

</comment></comment></comment></comment><comment><USER9> And here I entertained the thought that for Google the legislation was a form of regulatory capture.

<comment><USER10> It would seem that having to be GDPR compliant would dis-proportionally favor large companies with a lot of lawyers and engineers to implement the needed features company-wide.

If this is not working out for Google, perhaps it's because the business is fundamentally incompatible? But I have problems believing that. The outcome would be too good :-)

<comment><USER11> > perhaps it's because the business is fundamentally incompatible?

After having read most of the GDPR, that's my conclusion: all advertising other than 1990's style bannering now needs per publisher, per user, opt-in for anything that does tracking or is personalized, where the default should be set to 'no', denying should be as easy as consenting, and refusing access is not a valid publisher response.

That means i.m.o. that using any form of modern advertising has become illegal under GDPR, unless you get users to consent in a compliant way, and I have seen just a few sites even try. I think Google is scrambling to understand that their business is now mostly illegal in EU.

<comment><USER12> I don't think that would mean that Google's business is fundamentally incompatible. If 90's-style bannering is the only thing that is allowed/feasible now, of all companies Google is in the best position to do that profitably.

<comment><USER13> I think the GP means ads need to be served 1st party. For this, Google would be out, imho.

If Google hosted the ads, how would they not collecting your browsing habits? It's the same as with the embedded Facebook Like, which is in the same ballpark.

<comment><USER11> I didn't mean ads need to be served 1st party. I think GDPR does not prevent Google or anyone from hosting ads for their customers. Maybe it's hard to imagine, but it is really simple to host ads without tracking users... Google simply has to NOT DO it. And guarantee that in writing to the publisher.

Counting impressions and clicks are no problem, as long as no personal data is collected. But storing personally identifiable data for the click/impression (such as the full ip address, or advertising id in a cookie) needs consent. Unless you need (and only use it) to prevent fraud, which is a valid legitimate interest. Using it for (Re)marketing is not.

</comment></comment></comment></comment></comment></comment><comment><USER14> It is unfortunate that my essay didn't get much attention: [http://yuhongbao.blogspot.ca/2018/04/google-doubleclick- mozi...](http://yuhongbao.blogspot.ca/2018/04/google-doubleclick-mozilla- essay-final.html)

<comment><USER15> I'm sorry but your essay didn't get much attention because it is not particularly written well. I'm not really sure what you are arguing here, except that Google is bad maybe? You aren't clearly arguing an specific thesis, and there are many non sequitur paragraphs that don't flow. Why are you talking about OpenJDK in an essay about Google Adsense? Or is the essay about Doubleclick BMP?

If the point of this essay is to provide an overview of the area, I am not sure you are well educated in this area. For example, most of doubleclick publishers dont do retargeted ads. They tend to do BMP only. You didn't mention programmatic at all. You don't talk about ad networks. Also you don't mention that Google has done a lot in the area of malware both on the web in general, and specifically has spent a lot of resources in getting malware off the ad network. This makes you seem disingenuous, because while Google isn't a fully "neutral" actor, they are overall a good citizen in the ad space. Ad targeting isn't inherently evil, a lot of ad targeting is geographically based -- in fact many people would probably argue that showing geographically inappropriate ads is even worse -- others are consumer segment (eg: women/men/age).

I would like to have a non-advertisement internet, but it appears that people are just unwilling to do so. Also we may be facing very real cognitive limits, studies on microtransaction fatigue have demonstrated that is not likely to be a successful mechanism for funding webpages -- people just can't make that many monetary decisions every day.

<comment><USER14> There are other known problems with the essay as well. For example, I mentioned storage costs but it turned out to be more complex than that. The point is not only to provide an overview though but more importantly to trace back the problems to Larry/Sergey, which is why it is so important. And yes I focus on ad tracking using cookies and nothing else. When I was writing the essay BTW, even tracing back when they began sharing the retargeting data took some time.

<comment><USER15> You're making an argument, but I think you take it for granted that everyone knows what "the problems" are. I'm still not sure what that is!

Also, why is it important to trace the problems back to Larry/Sergey? What about the early engineers who worked on adsense? The early PMs? Surely they are just as culpable for "the problems" (which ones again?) as anyone else? I guess they aren't household names?

Also, adsense/doubleclick revenue accounts for 14.9% of total company revenue as per the last 10-Q filed. So it's a misrepresentation to discuss adsense/doubleclick as anything other than an important, but not critical, part of Google. Google could, in theory, lose all that revenue and still remain in the black.

<comment><USER14> There are also Google Analytics/Urchin though. Part of the point of the essay (and one of the hardest parts for me to write) is to figure out when they merged the tracking data after the acquisition. I would consider the DoubleClick one worse than AdSense BTW, which is part of the point of the essay.

<comment><USER15> Except, you're wrong. Ga data is never joined with other data sets.

<comment><USER14> What I was referring to is the sharing of remarketing lists. One example: [https://analytics.googleblog.com/2015/06/remarketing- lists-f...](https://analytics.googleblog.com/2015/06/remarketing-lists-for- search-ads.html) [https://analytics.googleblog.com/2015/11/share-google- analyt...](https://analytics.googleblog.com/2015/11/share-google-analytics- data-and.html)

<comment><USER15> Well later in the essay you write that google analytics is merged with ad data in an unqualified statement. That's what I was reacting to.

Remarketing lists is a feature that would be google neutral. I could imagine such a feature working for self hosted analytics.

<comment><USER14> And I mentioned in the essay that "In many cases, advertisers managed "remarketing" lists of "anonymous" visitors that was being tracked by cookies from a central console without thinking of the privacy problems, treating visitors almost as numbers." I wonder if such a use would comply with the GDPR BTW.</comment></comment></comment></comment></comment></comment></comment></comment></comment>


Show HN: I just hit my 500th TIL - <AUTHOR> https://github.com/jbranchaud/til/commit/9b48c11e2642fae072e21727f2c246423ed0ef23 <comment><USER2> I love this idea for keeping track of stuff you learn. Are you using some automated system, or just manually changing them?

</comment><comment><USER3> I'm quite surprised I never saw this before. It's a neat collection of small bits of wisdom.

</comment><comment><USER4> Nice!</comment>


Bots Are Hot (1996) - <AUTHOR> http://www.wired.com/1996/04/netbots/ <comment><USER2> Putting aside the nomenclature differences between 'bots' in today's media and bots in this article (defined, broadly, as a kind of helpful software), can someone tell me why entrepreneur/VC types are investing heavily in the ongoing submarine[0] that is 'bots'?

Serious question; I completely fail to see why there would all of a sudden be a gold rush here.

* There hasn't been some shiny new technology introduced (open source machine learning, maybe? Messengers with APIs have existed for a long time)

* There isn't some massive consumer shift happening that's new (messaging has been around forever. It's been crazy popular outside the US for a long long time.)

* There isn't some crazy new business model everyone's chasing

* There hasn't been some crazy UX breakthrough that solves text interface problems (high learning curve, ambiguity about what the service can do)

I can, however, understand why Facebook and Google want people to build bots on their new platform, hence the submarine reference.

Any ideas?

[0][http://paulgraham.com/submarine.html](http://paulgraham.com/submarine.html)

<comment><USER3> Because soon enough every company out there would want to include one in their website, regardless whether it's based on some half assed AI. Depending on how good the implementation will be, bots could solve some real problems in the customer support front. And there would be top dollars in training bots (aka customizing the software) to adapt to specific needs. Instead of having FAQs, which no-one ever reads, you'll have bots. And you could choose from a variety of them, starting from a few dozen bucks per month up to thousands.

There are hundreds of use cases I can think of. A doctor implements a bot on his/her site and it asks potential patients questions about their condition. It feels much more friendly than reading a FAQ. The same goes for a lawyer firm. Or how about a bank's call center. Actually, every call center out there could be replaced by sophisticated bots. Or a bookstore that asks you to name a few of your favorite books and then makes recommendations. Come to think of it, the market here is huge. That's why all the big players are moving in. Microsoft is already building APIs for their platforms.

As for Google, judging by the fact that they've invested shitloads of money in AI research, bots could really give them an opportunity to capitalize on that know-how.

<comment><USER4> >A doctor implements a bot on his/her site and it asks potential patients questions about their condition

And the bot misdiagnoses or has a malfunction, leading to the patient not getting the correct treatment they required. Yikes.

<comment><USER5> > _And the bot misdiagnoses_

vs. a regular doctor doing that? Which happens all the time, actually. Its really interesting how we expect computers to be far more accurate than we ever expect humans to be!

Of course, I'm being a little disingenuous: You can sue a doctor, you can't sue a bot.

<comment><USER6> > You can sue a doctor, you can't sue a bot.

But you can sue the company that made the bot, and the company that employed it. With humans the employer can often dump responsibility on the "fall guy" who made the mistake, while with bots you often have to (properly) consider any failure as a system problem.

</comment></comment></comment></comment></comment><comment><USER7> As a teenager I ran a pretty high margin business operating botting software for a popular MMORPG. Bots would autonomously play characters in the game in order to "farm" items that could be sold to other players in the game. Virtual currency could then be transferred over a "black market" forum, usually with paypal as a medium. Just to be clear all this was legal, it merely took on the visage of "illegal" because it violated the TOS of the game and could you your in-game character(s) banned.

The software was written by mostly teenagers and by all modern metrics was absolutely atrocious. It required constant maintenance, crashed all the time, and was riddled with bugs that would reveal your character as a bot and get it banned. But the exchange value for the virtual currency was so high it didn't matter, I was still making hand over fist.

I didn't write any of the software I used at the time but it's a pretty frequent daydream of mine imagining the literal millions of dollars I could of made were I able to go back and re-write that software knowing everything about software development I know now.

The beauty of bots is that they do not augment the productivity of the user like most software, they replace it with something that is a consistant multiplier better.

<comment><USER8> As someone who has rewritten software with the benefit of hindsight and experience... I'm still in awe of how simple and functional my old (sometimes crashy) code was without any forethought.

<comment><USER9> Yeah, one of the first professional jobs ca. 2001 was to replace the student group registration form and database at my 40k-student state university. I replaced an old ColdFusion app with a few pages of PHP backed by MySQL. The design was horrendous, the error handling worse, and yet somehow it was an incredible leap forward in terms of performance and UX.

I think the bottom line is that there is often very juicy low hanging fruit that you can get to just by a minimal amount of knowledge and sheer force of will. The deeper knowledge and experience will give you a lot more things to think about which will help with edge cases, scalability, maintainability, robustness, etc; but while those things may be necessary for some projects, in many cases they end up bringing only small marginal gains.

I'm at the point in my career now where I'm actively cultivating beginner's mind to avoid being paralyzed by my knowledge of all the ways things can go wrong.

</comment></comment></comment><comment><USER10> WebVan -> Instacart, Amazon Fresh

Napster -> Spotify

Chatbots (1996) -> Chatbots (2016)

Just because an idea failed, doesn't mean that it's resurrection is necessarily derivative or vacuous. Timing is everything, 20 years is a lifetime for applications of tech concepts.

<comment><USER11> Ideas never fail. Just the execution of them. Which heavily depends on a wide array of factors.

<comment><USER10> That's a little pedantic. I would say that the idea includes the plan for execution, and in many cases perfect execution cannot resuscitate an idea that is too early.

<comment><USER11> Its black and white (at least in my opinion). I have an idea for something. How I bring it to reality and under which circumstances will either tell if my execution of the idea fails or succeeds. But the idea is still there. In a sort of idea limbo of sorts.

</comment></comment></comment></comment><comment><USER12> Yeah, but it's different now. Now we have AI buzzwords!

<comment><USER13> We also have many orders of magnitude more computing power on which to implement the concepts behind those buzzwords. Maybe it'll make a difference.

</comment></comment><comment><USER14> Someone tell me a bot I should try to become convinced bots are the next big thing.

</comment><comment><USER15> "But one thing is certain: the numbers and varietiesof bots are exploding. The bot diaspora has begun."

</comment><comment><USER16> Darn. I assumed this was about HotBot based on the title and date.

[https://en.m.wikipedia.org/wiki/HotBot](https://en.m.wikipedia.org/wiki/HotBot)

<comment><USER17> It is incredible to me that not only does that site still exist, but it has an Alexa ranking of 124,967 as of Feb 2016

</comment></comment><comment><USER18> Heh, 1996. I'm suddenly nostalgic for the era when the Net was new and Wired was still edgy and exciting, instead of just one more content mill.

</comment><comment><USER19> Spent a few years developing a bot with similar features to Alexa, called LFReD back in 1998. Was possible to carry on a conversation with LFReD via cordless phone, control lights, look up wikipedia articles etc.

Idealabs approach me at one point offering to buy my botsinc.com dom.

Two things killed development. The first was the quality of the speech recognition. 85% accuracy sounds impressive, but in real life, it's terrible, especially combined with background noise. (I had a love bird that would squawk every time i tried to train the recognizer :) The SR has only recently caught up enough to be acceptable (just). The other was the AI. Every 'rule' had to be hand coded. eg: "if SR = 'hello world' then tts 'hello'". I don't think they'll get past that last issue anytime soon, and I believe the Loebner prize is still very safe.</comment>


Ask HN:Is there any uncensored search Engine  - <AUTHOR>

<comment><USER2> > Is there any uncensored search Engine

"Censored"? What do you mean? Can you yell "fire" in a crowded theater? Can you libel someone and expect no sanctions? Can you upload and download copyrighted materials? Can you post state secrets? If any answers are "no", then there are no uncensored websites or search engines.</comment>


Performance of sequential Rust programs - <AUTHOR> http://pcwalton.github.io/blog/2013/04/18/performance-of-sequential-rust-programs/

<comment><USER2> I think this speaks to conscientious language design combined with the use of LLVM as a backend.

Pretty excited about Rust, it's the best (virtually) no-compromise developing option for systems work.

Curious to see where it starts to actually bite people as popular use grows. I really wish they'd put more effort into community/outreach though.

<comment><USER3> /r/rust is great. Mozilla/#rust is great. I think a bit of it simply has to do with Rust's immaturity. For example, there are no real http libs client or server to speak of because the scheduler rewrite is blocking. Oh well, I get the impression that stuff is all simply a matter of time.

Pcwalton's blog is great if you're interested in more rust stuff.

<comment><USER2> I've spent some time in their IRC channel and tried to use the language at a few points. They're nice people but not really interested in helping anybody use the language that isn't an intern working on it. Or at least, that was the case at the time I was on Mozilla's IRC server.

The language isn't positioned for wider use the way Go was when it was first announced.

<comment><USER4> That's because we announced the language earlier in its lifecycle than did Go, relatively speaking. (Graydon had initial designs for quite some time before development really started, which is why you sometimes hear that the language is older, but development didn't really start until 2009-2010.)

We're definitely interested in helping people learn to use the language. Hence the tutorial, Niko's, Brian's, and my blog posts, and so on.

Of course, the manual and learning material are in dire need of improvement in many areas; please bear with us, as it's a work in progress.

<comment><USER5> I've tried learning Rust twice. Once when 0.4 was announced, and then again a few days ago because of 0.6. Both times I read the entire tutorial and manual, and poked around the standard libraries. But both times I ran in to the same problems. Both the tutorial and manual contradict each other in places, and contradict themselves in places too (e.g. I saw both &'r foo and &r/foo syntaxes in the 0.6 manual). The manual is also full of broken links (every time it referenced another section of the manual, the link didn't actually do anything). And the tutorial doesn't actually have anything for you to do as you work along it, it's basically just a rephrased manual with a bunch of tiny code snippets. The library documentation is formatted really poorly and makes it hard to figure out how you're supposed to do something. And just in general, there's no good examples of how to actually write idiomatic Rust code, or how to write a full program.

I recognize that it's a work in progress, which does excuse a lot, but these problems do act as a significant barrier to actually using the language. I'd love to actually start writing Rust programs, but when I look at it, it just feels like I'd be better off waiting until the next release and hoping it's better. Which is a real shame, because a lot of what you're trying to do with the language really appeals to me.

Contrast this with the state of the Go documentation / learning material when it was announced. I was able to dive right in to that language, figure out how to write idiomatic code in it, and produce programs.

I guess what I'm trying to say is, I wish you guys would start putting more effort into the documentation side of things.

<comment><USER6> As Patrick said, Go was announced much later in the development lifecycle. Go was developed for quite a while before it was announced. At Mozilla, we do things a little differently. All of our projects are open and public from the very first commit into the repo.

People seem very excited about Rust and want to use it right away, which is great, but things have been changing a lot, as you noticed, and will continue to do so for a while. One of the reasons things are changing is because the Rust developers take into account the opinions of random early adopters of the language. There is no idiomatic way to write Rust yet because Mozilla wants the Rust community to help figure out what idiomatic code should look like. Go, on the other hand, has lots of opinions.

There are obviously tradeoffs to each approach, and one downside of the Mozilla approach is a lot of churn and chaos sometimes. However there are a lot of benefits too, one important benefit being that the community is helping to shape the language in an open way.

<comment><USER5> I have no problem with the community helping to shape the language. But I think the difficulty in getting started with the language, due primarily to documentation problems and lack of good introductory material, is going to make it harder for people to get involved.

I know when Go was first released I immediately jumped in and started using the language. I was even the first non-google, non-@golang person to get their name in the CONTRIBUTORS list (because I wanted to modify the emacs go-mode, but still). But I feel like I can't even get started with Rust because I have no idea what I'm doing and the documentation isn't helping.

For example, right now I'm trying to whip up a really tiny program to test out the FFI. But the libc module's documentation is completely nonexistent. It's just a series of nested modules, which end up having nothing in them. I'm sure there's actually stuff in the modules, otherwise they wouldn't exist, but the documentation claims that they're empty. So I have no idea what I'm doing.

<comment><USER4> The problem with libc is twofold: first, reexports don't show up in the docs (bug on file [1]), and secondly, that every module gets a separate page (filed as [2]). You can actually see the signatures for functions if you click through enough, e.g.

[http://static.rust- lang.org/doc/0.6/core/libc_funcs_posix01_...](http://static.rust- lang.org/doc/0.6/core/libc_funcs_posix01_unistd___foreign_mod__.html)

Having to click through is annoying, though. It would be better to be able to specify that a module and all its submodules should go on one page in the docs.

Thanks for the bug report!

[1]: <https://github.com/mozilla/rust/issues/3537>

[2]: <https://github.com/mozilla/rust/issues/5952>

<comment><USER5> Makes sense. Would fix the problem where I have no idea what prelude pulls in too.

Also, part of my confusion with libc is that not all of the leaf modules actually have something in them. The first few I looked at were completely empty, so I thought the entirety of the libc documentation was empty.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> As I just wrote on his blog, based on the GCC version he cites, it's not really GCC, it's LLVM with a GCC frontend.

(plus, if it was really 4.2, it'd be a 5+ year old version)

Not to mention, LLVM 2.9 is pretty old as well.

Plus, you know, without explaining what options were used, it's impossible to tell anything about anything.

<comment><USER4> It's really GCC 4.2, not LLVM. I used -O2 for GCC and clang and -O (which runs LLVM in -O2 mode) for Rust. Updated the post to mention the options.

Edit: Added clang 3.1, trunk 149587. Over 2.9 it has some improvements, some regressions.

<comment><USER7> Great, thanks!

</comment></comment></comment><comment><USER8> Please stop using OS X as a benchmarking platform. It lacks an official package manager and you'll end up using very old software (GCC 4.2 is from 2007-2008) because it's hard to install recent versions.

</comment><comment><USER9> Does Rust have any kind of GUI stuff yet? Last time I looked it was just Cocoa wrappers.

<comment><USER10> Are you talking about a high level toolkit? Wrappers around the native platform API is the starting point for any GUI toolkit.

<comment><USER9> Something a bit more cross platform like wxWidgets or GTK (well sorta)</comment></comment></comment>


Why corporate IT should unchain our office computers - <AUTHOR> http://www.slate.com/id/2226279/pagenum/all/ <comment><USER2> There is an argument to be made for less restrictive IT rules. As someone who sets the policy for an IT department I tend to allow any of the normal sites on the theory of "people with computers should be trust worthy already and those people have lunch breaks so why not trust them with access to sites like Facebook or Myspace (at least until it's abused)"

But this author is a tool.

First, anyone whose dealt with consumers in general knows that most computer users get themselves into trouble doing benign things. For example, in my experience, most people get malware while searching for pictures on Google. They find the picture they want, click on it and before you know it they're infected. So how trustworthy they are isn't really an issue.

Second he dramatically misunderstands the laws he quotes. On Sarbanes Oxley Gmail IS a violation because S.O. requires the companies themselves to archive all e-mails. So if he leaves and takes his gmail with him than he'll have an archive but the company will be in violation. As for his fiance, the Medical Professional that can't use IM, any IT person in Health Care will tell you IM programs are a HIPAA violation because they allow for encrypted transfer of files and hence represent a risk to medical records (I work for a mental health organization and we have to scan at our firewall for files going out and have protection software to prevent certain files from being copied to flash drives)

I guess what I'm saying is there are certainly IT people who take security too far. But, as this writer proves, there are also users who ask for too much.

<comment><USER3> Why should an IT person get to decide what sites are non-productive? Ridiculous.

I like this article on Google's approach: [http://www.cio.com/article/144500/IT_s_Third_Epoch...and_Run...](http://www.cio.com/article/144500/IT_s_Third_Epoch...and_Running_IT_at_Google)

"On Sarbanes Oxley Gmail IS a violation because S.O. requires the companies themselves to archive all e-mails. So if he leaves and takes his gmail with him than he'll have an archive but the company will be in violation." The article clearly stated he was forwarding his email to gmail- so you are the one that has it wrong, the company would still have a copy. The problem here would not be SO compliance, but rather corporate document retention (destruction) policies where they want to get rid of records as soon as it is legal to do so.

"any IT person in Health Care will tell you IM programs are a HIPAA violation because they allow for encrypted transfer of files" Do you mean unencrypted? Regardless- I can think of 100 ways to transfer an unencrypted file. Why single out IM, which has many useful properties.

Here's what's happening in the real world- the corporate network/desktop that is overly locked down gets circumvented. People bring in laptops and use cell modems, people use their phones, people install virtual machines.

<comment><USER2> I really don't know how to answer your first question without sounding a little rude so you'll have to forgive that but the bottom line is if the IT dept. gets to pick which sites are productive it's because the company has entrusted them to do so and the company owns the equipment so it's their right to control how it's used. Though a good IT dept. will listen to individual employees and allow sites they might not normally allow if there's a good reason.

On Gmail the question was "why were they banning Gmail" not was his personal use of gmail a violation so the point still stands (though I'll admit I read it wrong)

Finally, if your security gets circumvented than your security is flawed. Any IT department that chooses not to implement security on the argument that it will inevitably get circumvented probably needs to re-evaluate how they're handling things.

<comment><USER4> Most financials don't care if it's your personal email you're going out to Google for. I've seen people get fired for that --- and just for that.

</comment></comment></comment></comment><comment><USER5> This article is depressingly bad.

Even a sysadmin runs their computer as root or sudo 2% of the time and should not run non-SOP software on a work computer...

How could you manage giving regular users the ability to install while maintaining a secure environment?

On our networks website restrictions are for bandwidth reasons not for 'net- nannying' reasons. And occasionally be have to adjust for silly dansguardian mis-flags...

But how can you seriously argue what this guy is putting forth?

I have played with the idea of giving users a VirtualBox install of Win XP that they can trash to their heart's content while having a more secure Linux desktop for the work applications (Firefox/ Thunderbird/ OpenOffice). But I am not convinced that is really secure. But that is more the way to go with something like this.

<comment><USER3> "How could you manage giving regular users the ability to install while maintaining a secure environment?" Don't put your important data on the desktop. An intranet app over VPN is definitely safer than walking around with the company data on a laptop.

I like your idea of giving people an virtual machine to worth with. I use virtual machines to do a lot of real work (as a contractor) where the corporate IT policies don't let you do work.

</comment></comment><comment><USER6> I wouldn't be surprised if in a few years more tech savvy employers require/allow employees to bring their own computer. With better "type 1" hypervisors, you could have your Home OS image and your Work OS image running at bare metal speeds with the ability to simply flip between the two.

Employers could save money and employees could do whatever they wanted on their "home" OS.

</comment><comment><AUTHOR> Perhaps this would be better as an Ask HN:

What kind of IT restrictions (if any) do startups here impose as they grow beyond founders?

<comment><USER7> I work for a software startup that has grown to about 30 people. Last month we had a "security week" where the entire engineering team worked on. As usual, we audited our own product and wrote some code to make things more secure. But we also found that our internal desktops were one of our biggest -- and most unprotected -- attack vectors.

In response to that, a couple of our engineers developed an IT policy for corporate computers. These are laid out as relatively straightforward requirements, like "you must not use IE 6", or "you must edit the registry and change the default timeout of the Beezlebop service."

These prescriptions were written up as corporate security policy, although employees are trusted and no one is policing it. If you have a legitimate business need to ignore a policy, like needing IE 6 around for testing, then no one's going to stop you. But be smart about it and don't use that browser to download warez.

I like the free and unrestricted nature of working for a startup, but I completely understand the rationale for these policies. Everything they recommended was due to known security holes and known vulnerabilities in default installations. It's irresponsible NOT to fix these holes. If our security was compromised because of a long-known Windows attack, it would make us look awfully stupid.

</comment></comment><comment><USER8> What does everyone think about the idea of having fairly minimal IT restrictions, but requiring the use of tools like Rescue Time? Would you take that tradeoff?</comment>


CIA Concludes Russian Interference Aimed to Elect Trump - <AUTHOR> http://www.npr.org/sections/thetwo-way/2016/12/10/505072304/cia-concludes-russian-interference-aimed-to-elect-trump <comment><USER2> The CIA:

-Funded and militarized terrorists in foreign countries^6

-Funded Blood and Crips gangs in California through drug smuggling^1

-Facilitated distribution of crack cocaine, contributing to the explosion of crack cocaine in America (The reporter who broke this story was later found to have died to two gunshot wounds to the head. It was ruled a suicide)^2

-Influenced media and created propaganda through Operation Mockingbird^3

-Claimed 'Iraq has weapons of mass destruction.' No such weapons were ever found

-Funded Jihad and Islamic fundamentalist terrorist groups^4

-Carried out an illegal and failed invasion of Cuba^5

Sources: 1 [https://oig.justice.gov/special/9712/ch01p1.htm](https://oig.justice.gov/special/9712/ch01p1.htm) 2 [https://en.wikipedia.org/wiki/Gary_Webb#Dark_Alliance_series](https://en.wikipedia.org/wiki/Gary_Webb#Dark_Alliance_series) 3 [https://en.wikipedia.org/wiki/Operation_Mockingbird](https://en.wikipedia.org/wiki/Operation_Mockingbird) 4 [https://en.wikipedia.org/wiki/Operation_Cyclone](https://en.wikipedia.org/wiki/Operation_Cyclone) 5 [https://en.wikipedia.org/wiki/Bay_of_Pigs_Invasion](https://en.wikipedia.org/wiki/Bay_of_Pigs_Invasion) 6 [https://en.wikipedia.org/wiki/Iran%E2%80%93Contra_affair](https://en.wikipedia.org/wiki/Iran%E2%80%93Contra_affair)

Unfortunately, this list only covers errors of the CIA, and while it is far fall inclusive of all of them, there is, however, no doubt that they have also made contributions to the public good. I am merely pointing out that the CIA is not a purely altruistic and infallible source.

<comment><USER3> The CIA is an "ends justify means" organization. And I don't think the ends for them are anything other than "the good of the country" (whatever that means to them at the time). The shady (sometimes downright horrific) things they have done in the past have fit in with that idea. Within that framework, I don't think that they would make these allegations without either good reason to be worried about interference or good reason to be worried about Trump's ties to Russia.

Also, Bay of Pigs was far from an invasion. We didn't even send in air support!

<comment><USER2> > The CIA is an "ends justify means" organization.

Yes, so take what they say or do with a grain of salt. For instance, as I wrote, they told us they had proven Iraq had WMDs but that was later found to not be true.

> Also, Bay of Pigs was far from an invasion. We didn't even send in air > support!

You're manipulating the definition of invasion. An invasion is an invasion. Yes we did not send air planes.

And I already agreed with your point that the CIA is an organization whose intentions are allied with US national interests, I wrote that in my post actually.

<comment><USER2> Instead of downvoting, I wish people would say why they disagree

</comment></comment></comment></comment><comment><USER4> A couple of takes on these leaks, which seem to be at odds with FBI conclusions:

[https://www.emptywheel.net/2016/12/09/unpacking-new-cia- leak...](https://www.emptywheel.net/2016/12/09/unpacking-new-cia-leak-dont- ignore-aluminum-tube-footnote/)

[https://theintercept.com/2016/12/10/anonymous-leaks-to- the-w...](https://theintercept.com/2016/12/10/anonymous-leaks-to-the-washpost- about-the-cias-russia-beliefs-are-no-substitute-for-evidence/)

<comment><USER5> Another take from a former British diplomat and ambassador (Craig Murray): [https://www.craigmurray.org.uk/archives/2016/12/cias- absence...](https://www.craigmurray.org.uk/archives/2016/12/cias-absence- conviction)

</comment></comment><comment><USER6> Very relevant: See Hypernormalization 2016.

I am mindful about all the hoopla about the CIA not being the most reliable source, but, I have to be honest, I see it and I'm sure a lot of us see it everywhere, on any article that is critical of putin or Russia, floods of comments that extol Putin's strength or simply try to discredit the messenger. This is similar to their MO, confuse and make the public unsure of what is true or false.

This sounds conspiratorial, but I feel I've seen this sort of astroturfing first hand.

</comment><comment><USER7> Has anyone seen anything resembling a fact or evidence in all of this?

It wouldn't shock me, given the poor state of the political party's email security, if the emails had been retrieved by multiple entities. I haven't seen anything that illustrates evidence of Russian gov involvement, anything that connects it to an information release, or anything that connects that to intentional election tampering.

It seems more than a little speculative at this point.

</comment><comment> chroem- The last time the CIA went to the media with supposedly incontrovertible evidence we ended up invading Iraq over WMD's that didn't exist. Food for thought.

<comment><USER8> [https://en.wikipedia.org/wiki/Office_of_Special_Plans](https://en.wikipedia.org/wiki/Office_of_Special_Plans)

</comment></comment><comment><USER9> "the CIA protesting a right wing president being installed by a foreign power might be the funniest thing that has ever happened"

</comment><comment><USER10> Sadly nothing will actually come of this because we're all too lazy and comfortable to care.

<comment><USER11> I wouldn't say lazy quite yet. I'm still in shock that Republicans have done this to the country. Their infatuation with Putin and Trump's open collusion with him are stunning.

<comment><USER12> > Trump's open collusion with him

Can you provide some proof of this 'collusion'?

<comment><USER6> The linked article?

Also, this is probably nothing that severe, but Ivanka Trump vacationed with Putin's girlfriend[0]...they have indirect personal ties, at least.

[0] [http://thehill.com/blogs/in-the-know/in-the- know/291465-ivan...](http://thehill.com/blogs/in-the-know/in-the- know/291465-ivanka-trump-vacationing-with-putins-rumored-girlfriend)

<comment><USER13> Putin girlfriend is _Chinese_ _married_ woman? LOL

Russia will eat Putin alive if this is true. Do you have any evidences for that, please?

</comment></comment></comment></comment></comment><comment><USER14> @dang: Curious to see if the "no political posts" guideline applies to this -- why or why not.

> If they'd cover it on TV news, it's probably off-topic.

<comment><USER15> The experiment was official concluded two days ago.

[https://news.ycombinator.com/item?id=13131251](https://news.ycombinator.com/item?id=13131251)

<comment><USER14> It's still in the guidelines: [https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

<comment><USER16> That's the same rule that has been there for years and not related to the "experiment".

</comment></comment></comment></comment><comment><USER13> Russians are aimed to elect Clinton, because republicans are natural enemies of Russian dictatorship, while democrats allowed them to start war and capture part of Ukraine despite Budapest memorandum.

<comment><USER17> How, exactly, does TFA fit in to this theory of yours?

<comment><USER13> I have no idea what is «TFA». However, I am in war with Russia and I welcome republicans, so I assume that Russians are opposite to me.

<comment><USER18> TFA = "The Fucking Article". The article that this comment thread is attached to.</comment></comment></comment></comment>