MS and Apple have the same thing, they're just less successful. Just a browser and an OS was previously seen as antitrust (and it looks like MS is being anti-competitive in this space still). Just a browser and a search engine can allow anti-competitive behavior. Or just a search engine and an ads platform...
The problem is the anti-competitive behavior. Businesses are generally rational actors, so clearly our system isn't working. It's unclear what the boundaries are until years in court, and even then it only applies to a single company.
A company owning a web browser isn't the problem. A company owning a web browser, OS and search engine shouldn't be a problem either. I don't know why the remedy can't actually address the problem, and the DOJ can't move more quickly to address antitrust across the industry. This feels like randomly cutting a baby in half, while the rest of the thieves, even those in the same family, are not deterred.
If you could pipe the ripgrep output into an editor, make changes, and have them applied, that would be great. Once you get all the text you want to change in one buffer, it should be easy to make repetitive changes quickly in your editor of choice.
> Additionally, a subset of low entropy variations are included in network requests sent to Google. The combined state of these variations is non-identifying, since it is based on a 13-bit low entropy value (see above).
Author doesn't actually know what this information is being used for. Sure there can be a discussion about whether this information should be recorded at all (say, to determine if your site doesn't work on certain hardware), but claiming it _is_ fingerprinting is baseless.
> It probably also helps that extending Atom is much more approachable given that it's all Javascript...
I've heard this said before, I've had the opposite experience. ST offers a small api and it was easy for me to make something work with a single .py file.
I gave up trying the same thing in Atom; the api is larger and lower-level. Admission: I don't know coffeescript.
ST of course isn't nearly as flexible, there are many things you just can't do.
No high ranking USG official should be using insecure communication channels, as it will inevitably lead to leaks that could damage the state (secret information).
What Clinton did was dumb, but no one should have sent her classified emails in the first place. If the people sending the 'classified' documents were doing it through the right channels, it wouldn't be getting to her email server.
Don Knuth: As you say, I've come to believe that P = N P, namely that there does exist an integer M and an algorithm that will solve every n-bit problem belonging to the class N P in nM elementary steps.
...
My main point, however, is that I don't believe that the equality P = N P will turn out to be helpful even if it is proved, because such a proof will almost surely be nonconstructive. Although I think M probably exists, I also think human beings will never know such a value. I even suspect that nobody will even know an upper bound on M.
...
The moral is that people should distinguish between known (or knowable) polynomial-time algorithms and arbitrary polynomial-time algorithms. People might never be able to implement a polynomial-time-worst-case algorithm for satisfiability, even though P happens to equal N P.
This article seems to assume that problems in P are computable no matter the size. If it is shown NP=P, but the best algorithm we have is O(n^100), we still don't have a computer that can actually finish the computation.
Too many times I've 'solved' a Project Euler problem like this:
1. Write a program to solve the problem inefficiently.
2. Look up the sequence F(1), F(2), F(3) ... at oeis.org
Say I have 3 members that must be set, and 5 optional members. Go's solution is to make the 3 critical members private so that someone using this struct will probably figure out they should use a construction function. And doing this means replacing all code that creates my struct with calls to a 'New' function. With all this friction, people aren't likely to do the right thing.
At least in C++ with public members I can initialize appropriately in the constructor. Of course littering my code-base with public members would be bad practice in the first place.
'Use tagged literals for struct initializations'... I'd rather the compiler help me make sure i've updated all uses appropriately when I add a new field.
class Person { int age = 0; };
I wish rust would make default struct field values this easy to write.