280 karma · joined December 16, 2020
That is exactly my observation. When the good power Mac laptops came out a lot of my ThinkPad Linux laptop using co-workers jumped ship. Number one reason stated: battery life. Number two reason stated: suspend works reliably. Number three: it is POSIX/UNIX-ish enough that it is familiar and I can do my job.
Somewhere along the line in school I realized that whenever I had a question most often many other people did too. I lost my fear of asking questions after a lot of feedback from others: "I'm so glad you asked that question, I was completely lost!"
In my career I realized that nothing had changed, and that asking for more clarity is almost always a good thing.
I posit that this kind of "deal killer" is most often a wish list item and not a true need. I think most teams without a working product think these kinds of theoretical reliability issues are "deal killers" as a form of premature optimization.
I worked at a FANG doing a product where we thought availability issues caused by sessions being "owned" by a single server design was a deal killer. I.e. that one machine could crash at any time and people would notice, we thought. We spent a lot of time designing a fancy fully distributed system where sessions could migrate seamlessly, etc. Spent the good part of a year designing and implementing it.
Then, before we finished, a PM orchestrated purchase of a startup that had a launched product with similar functionality. Its design held per-user session state on a single server and was thus much simpler. It was almost laughably simple compared to what we were attempting. The kind of design you'd write on a napkin over a burrito lunch as minimally viable, and quickly code up -- just what you'd do in a startup.
After the acquisition we had big arguments between our team and those at the startup about which core technology the FANG should go forward with. We'd point at math and theory about availability and failure rates. They'd point at happy users and a working product. It ended with a VP pointing at the startup's launched product saying "we're going with what is working now." Within months the product was working within the FANG's production infrastructure, and it has run almost unchanged architecturally for over a decade. Is the system theoretically less reliable than our fancier would-be system? Yes. Does anybody actually notice or care? No.
[...]
> ...having seen some of the internal discussions, I trust Brave a lot when it comes to privacy.
I felt similarly about Google while I worked there. There were and still are a great many very skilled people focusing on security and privacy within Google, with good intentions. I personally had my own work vetted multiple times for security related stuff, and I was quite impressed.
Yet, Google has grown a bit of a PR problem with respect to privacy issues.
The (potential) problem is structural. Commercial entities exist to make money for investors. Protecting user privacy is a different goal. We also live in a world of grey areas, so judgement calls need to be made.
What structurally prevents the Brave corporation from changing once those people leave, leadership changes, acquisitions happen or Brave is acquired?
I see no particular structural reason to trust Brave more than Google. They're both companies that go to great lengths to respect and preserve user privacy. They're both corporations that exist to make money for investors.
What would I trust even more than Brave or Google? Something run under some form of governance that is legally accountable at a primary and structural level to what it is actually aiming to provide (e.g. privacy) rather than to making money (most every corporation in the world).
I think of it this way: we have both SIGINT and SIGTERM for a reason. One "interrupts" and the other "terminates" and there are often good reasons to handle "interrupt" differently from "terminate" -- at least in interactive programs.
I very much want the benefits of these kinds of systems, but they both produce a run time system (shell environment, whatever) that is not typical of how most people use software. So, while most other people are helping each other out with the "usual" problems, Nix/Guix users have a different set of problems. Sure, they are reproducible problems often shared by all other Nix/Guix users, but those communities are niche compared to what is typical.
Same with flakes. My impression is that Nix is either on the cusp of a major paradigm and usability change, or the status quo will be forever in a state of having "wrong defaults."
Funny you should mention that workflow, because Google highly values reducing the number of times users have to do that kind of iteration. If they can work out what you actually mean and give you that first time, they count it as a win and stick with that approach.
> Having the search engine make these opaque decisions on what it thinks I meant to search makes it feel like playing a game of Peggle, where I have no idea if what I'm going for will be what I get.
I think on average this kind of "semantic search" works out for the better, for most people, most of the time.
I tend to like precise results too, but I often appreciate Google applying its "magic," so I'm not sure Google running in a "all magic suppressed" mode by default would be better. E.g. I recently searched for help with an issue I'm having with my refrigerator. I searched for "Samsung BLAHBLAHBLAH drawer freezing" where BLAHBLAHBLAH was my fridge's model number. The search results included stuff for other similar Samsung refrigerators, which are all very similar, so the results were quite relevant to my problem.
Internal users demanded the upgrade every two years anyway.
I immediately thought: well what about Go for command line tools? Is this the viddy you speak of? https://github.com/sachaos/viddy If so, looks like it is written in Go. Looks like fzf too.
We’re getting there with FP, too. OOP…which kind? FP…which kind?
As far as usability, I do think computers have become easier for non-experts to use, especially for basic tasks. I definitely remember helping some very confused people being completely overwhelmed by what to click on, what deeply nested menu was needed, etc., when just trying to browse the web or check their email. Those basic workflows have gotten better.
In many ways I think modern interfaces are more about mobile first, touch based influences, and moving away from keyboard and multi-button mouse based interfaces. Stripping things down to the very basics is almost required now, given the devices people use. You can't "middle click to paste" on an iPad.
There are people who find working primarily in a terminal (usually, multiple) better for them. Perhaps by no coincidence, I've noticed that these people tend to work in circles where HTML email is not common, so there is little gain in "going GUI" for email.
Terminal programs, by definition and necessity, have a focus on efficient and comprehensive keyboard navigation. It is a rare GUI program that maintains a similar focus on keyboard navigation. (Thunderbird might be one, I don't know)
You can ssh into a box somewhere and use terminal programs and they feel native. Remote access to GUI programs is usually a larger compromise.
I tend to feel much more "in control" of my email workflow when I can set up complex filters, which usually leads me away from IMAP and toward email on the local disk. I've found that "old school" mail programs handle this use case better than GUI ones (which are usually focused on IMAP).
So, personally, I'm either reading mail from local storage with an old-school mail reader (for very high volume, tech related, work related, stuff), or going full cloud and using webmail (for lower volume personal mail). That way I can always get to my mail from anywhere, seamlessly (be it ssh or a browser).
I think this is most clearly described by two things Fielding wrote (and the original article links to):
https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...
https://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypert...
If leaky abstractions are unavoidable, we're left with debates about which leaky abstractions are justifiable given the constraints and goals of the design.
I don't think Microsoft has any particularly secret sauce here, they just have a good reason to keep it going and the money to do so. Many other cases the money just isn't there.
And don't under estimate the herculean efforts Microsoft goes through, or eat least used to go through, to keep old programs running. It goes far beyond what I would have ever imagined had I not talked to some of the people involved with it. We're talking having the OS detect specific versions of specific programs (e.g. old versions of Quicken) and hot patching specific APIs with bug-compatible behavior so they don't break with an OS upgrade. Microsoft definitely takes backward compatibility seriously.
As for your "side quest off a side quest" observation, I think that is a matter of perspective, about what personally motivates you, and about how work is organized in society. I find that working at a small company makes it easier to have a feeling of focus and purpose -- everybody is focused on one thing. But, I find that working at a large (profitable, well run) company makes it easier to feel like you can actually move the needle and have the resources do large things (and yes, this includes a connection between something like a 'build tools' team and being able to ship a quality product more quickly).
It is easy to miss that every race car needs a pit crew, every pit crew needs equipment and parts, getting parts requires suppliers, parts need to be built, tested, etc., all those people need to eat, all that food needs to be grown, and so on. Organizing all of that "work" into small single-purpose companies, that buy each others' stuff, is one way to go. Another way to go is to organize it into larger companies with sub-teams/groups/departments. So a company's larger mission might be "win races" but, if it is large enough, smaller support efforts in support of the larger goal can make a lot of sense.
Or, as I sometimes think of it, it can be an OOP design if multiple dispatch is actually a set of messages supported by an implicit, singleton, and usually hidden, “multiple dispatch“ object that handles the dispatch logic. You don’t have to write “dispatcher.cast(a, b, c)” but that is because the language provides the syntactic sugar (and often, an efficient implementation).
I also think there is a cost to using a non-mainstream technology that is often overlooked or under-estimated. I also think the benefits of non-mainstream languages are often over-stated. In other words, when you really look at the details the cool/niche languages do often have notable drawbacks. I suspect that for most organizations the pro/con or cost/benefit comparisons of C++ vs. D don't often come out in D's favor and never did.
In the early days D chose to use GC which today, and for the past 30 years I have done C++ work professionally, has always been a dis-qualifier (mainly because of the extra memory overhead involved as well as the GC pauses). I have always looked at D with some interest, but never come close to formulating an argument that I could take to my company and suggest we start using D where we currently use C++. C++ almost uncompromisingly holds true to its backwards compatibility goals with C and the early versions of itself. C++ also almost always holds true to its "zero overhead abstraction" goals. D chose GC and replaced its standard library at one point. It is an interesting language for sure, but I think there are some things C++ has done better, from a practical use point of view, at least for the use cases where its use is still justified today, by being a more conservatively designed language.
Personally, I have sent these kinds of PRs out and received only approvals and thanks from maintainers. When in an approver/maintainer role myself, these kinds of PRs are trivial to approve and I appreciate them. The PRs that change a bunch of stuff, are large, hard to review, poorly described, poorly justified, poorly tested, etc., are the annoying ones.
Are you saying that there are people at Google whose job description is to tweak Google web products to perform worse on Firefox, just so Chrome appears better in comparison?
As a more casual person looking to use a license, this is basically the opposite of what I want to read.
As a non-lawyer, I have little chance of vetting a license myself. As a person with life experience, I have full appreciation for the delicacy of these kinds of licenses and legal issues.
If a license has consensus from OSI, FSF, Debian, maybe a FANG company or two, etc., then I have some trust that a kind of validation and peer review has occurred. I fear that using a license for which this has not occurred puts the users of my software at risk, or at least shifts the burden of future validation on to them.
TLDR: everybody knows what MIT, BSD, Apache, and the various GPL licenses imply. I think other bespoke licenses have a pretty high bar to clear before they become truly useful.