A quick look at the source shows that it appears to be linear and just uses `strings.Contains` or `r.MatchString` on each line, so I don't think it has any of the optimizations that are built into `ag`.
That is correct. The project is at its early stages. I want to see what the community need the most and shape the project towards that goal. On the other hand I tried to avoid optimisations until most of functionalities are implemented.
It's a very nice idea and you should be proud of what you've built, but my personal opinion is that speed is a core feature of `grep`.
A good place to start would be this: why GNU grep is fast[1] - Starting with the Boyer-Moore string search algorithm and reading through the optimizations done in GNU grep.
p.s. there's an implementation of Boyer-Moore hiding in Go's standard library.
So far I've been only concerned about code's simplicity until I understand what there needs to be done. This is not going to be grep or ripgrep. My intent was to make a tool I needed so I started working on it. I thought someone else might like it, now it is joyful to see people are looking at the project.
There are a couple of places I wish I would have done better. Using bufio.Scanner actually bothers me a lot. Also in the Read() method it reads everything from all readers into a buffer instead of pulling what it needs to check.
In a pair programming situation, this is very useful.
And yes, one cursor. But you can have multiple terminal sessions open on your local machine, but only be connected to one common session. That defeats the purpose of pair programming though.
You both want to be focusing on the same thing, at the same time.
It's incredibly helpful to launch a service and ensure it's running, and allow a dev to see it running in action as well. You can also have a one on one situation where a dev might want to show you how to debug a running app or something like that vs explaining where it logs error messages after they occur.
With TLS, the symmetric encryption keys are always newly generated regardless of the cipher suite chosen; the difference with the ephemeral cipher suites is how the keys are communicated.
Without forward secrecy, the client chooses the premaster secret, encrypts it with the server's public key, and sends it in the ClientKeyExchange message. With forward secrecy, the client receives signed ServerDHParams in the ServerKeyExchange and responds with ClientDiffeHellmanPublic in the ClientKeyExchange.
The threat for http to https transactions is that man in the middle can rewrite, drop, or add data before the user reaches the https site. See sslstrip[0] for an example of this attack.
IPv10[0] makes IPv4 an extension of the IPv6 space. It'll be interesting to see if this takes off, but it doesn't really seem to solve the whole problem. All nodes in the path would have to support IPv10 for it to work.
The internet-draft you linked is not a proposal that anyone should take seriously. Here is an actual, non-mocking review of that I-D: https://www.ietf.org/mail-archive/web/int-area/current/msg05... . To put it diplomatically, that author does not seem to have a proper understanding of IPv6 deployment nor of any relevant prior art.
There is neither "rough consensus" (besides that the author should have their posting privileges on the IETF lists removed) and certainly not any "running code". They've been trying to get IETF people to care about their harebrained "IPv10" scheme since November 2016; that they have yet to realise that their scheme is useless and that nobody seriously cares is about as depressing as seeing that internet-draft getting cited.
I was a bit surprised to see that it wasn't published on April 1 and got renewed multiple times.
Some parts of it are laughable such as
IPv10 support on "all" Internet connected hosts can be deployed
in a very short time by technology companies developing OSs
(for hosts and networking devices, and there will be no
dependence on enterprise users and it is just a software
development process in the NIC cards of all hosts to allow
encapsulating both IPv4 and IPv6 in the same IP packet header.
But it does have an interesting take on stateless IPv4 <-> IPv6 communication, specifically IPv4 -> IPv6. Obviously it wouldn't work as described without a full deployment, but it seems like something could be done there.
For instance, if an IPv4-only host wanted to communicate to an IPv6-only host, it could send packets to a well-known NAT46 anycast address with an IP option of the destination host. The NAT46 host could then create the IPv6 packet with the correct destination and IPv4-mapped source.
He suggested using the IPv4 routing table for IPv4-mapped IPv6 addresses, which wouldn't be loop-free unless every router was dual stack and did the same thing. However, with what I described, it seems like any dual-stack host (or router) could perform the translation in a loop-free manner.
- Understands that the proposal requires that "anything [that] will process a L3 packet" be upgraded to understand the new packet format, but seems to believe it's a simple matter of making the OS developers (which are "few") "push new updates globally".
- Seems to believe having the proposal ratified by the IETF is both necessary and sufficient for the proposal to be adopted everywhere.
