Ubuntu loves to mess with upstream by shipping a bunch of vendor patches. It's one of the main reasons I run Fedora, they do this the least in my experience
224 karma · joined July 27, 2008
We provision them with ~200 lines of shell script, which we get away with because they are not running a "prod" workload. Don't forget to run "docker system prune" on a timer! Overall these machines have been mostly unobtrusive and reliable, and the engineers greatly appreciate the order of magnitude reduction in github actions time. I've also noticed that they are writing more automation tooling now since budget anxiety is no longer a factor and the infrastructure is so much faster.
I've been using Linux since Slackware installed from a pile of floppy disks. I'm extremely happy with systemd (desktop and server) and view it as one of the most important UX advancements ever made in the Linux sysadmin space. It replaced a smorgasbord of broken nonsense with a unified and thoughtful system that is objectively superior to what it replaced. I suspect a lot of the extreme reaction to systemd is not just resistance to change, but based on an emotional attachment to the rag-tag heterogeneity it made obsolete.
My verdict is: the hardware is usually GREAT but MacOS isn't. It bothered me when I quit the platform ages ago, and it is still bothering me now: little I care about has changed or improved. New annoyances though!
In aggregate I'd say I've spent ca. 15 hours staring at the beachball. Intrusive admin software has been a problem in the past for sure -- especially at Google -- but I've bought dozens of these for home use as well. Either 90% of their units are defective or we're using our computers very differently.
Terrible keyboards are another thing entirely, Lenovo went through a bout of that with the X1. My gripes about Macs are almost entirely about OSX performance/reliability and command-line habitability: version over version, it almost never improves. For my workflows
I see people in this thread complaining that Linux distros are unreliable, but my Linux machines don't do things like beachball for 20s at a time or have complete audio system crashes requiring reboot twice a week. (Always right before a videoconference! I missed fifteen minutes of a call last week scrambling to fetch another device because the audio subsystem died and the Mac decided it had to install updates for a half hour when it rebooted.)
It's not uncommon to see uptimes on my ThinkPads measured in months. The Mac? At least it boots fast. I have to restart it once or twice a week.
Reliability aside -- and I realize that everyone values ergonomic factors differently -- Linux is just a better choice in every regard for me and the kind of work that I do. Interactive performance is much better, the docker-based workflows everyone's using are so much faster when they're native, and there's no mismatch between Darwin's BSD userland and the Ubuntu/CentOS you're probably using in prod.
Completely agree that out-of-the-box Emacs experience is NOT where it's at. I have twenty years invested in tweaking it to minimize keystrokes and operate faster for my use cases. Just remember that Emacs is not actually an editor, it's a Lisp Machine OS you can use to build an editor out of parts
Also keep in mind that alternate distros like Spacemacs are the way Emacs has to evolve, because making drastic structural changes to defaults would break so many user scripts and packages -- the things that provide most of the long-term value proposition of using Emacs in the first place.
I don't run the whole network IPv6 -- for hosts I care about having an IPv6 egress for, I use a Wireguard tunnel in IPv6 private address space to a bastion host. If I want to expose a port, I forward it from the other side. It's a sad state of affairs :-(
Given that postgREST exists, I don't see any reason to talk to postgres directly from a JS app.
If I need more nines of uptime than a single system could provide (and think about the MTBF numbers for the various parts in a computer, a single machine is not going to give you even three nines of uptime), then I'm literally forced to go distributed with N >= 3 and geographical redundancy (we stay up if any k of these machines fail, or if network to "us-east-4" goes down). Things get worse (and you need to be more paranoid) if your service level obligation turns into a service level agreement, because then it usually costs you money when you mess up.
Of course, the more distributed you are, the slower and more complicated your system becomes, and the more you expose yourself to the additional associated downtime risks ("oops, the lock service lost quorum"). They usually cost more to run, obviously. C'est la vie. There is no magic bullet in software engineering.
It used to be that you could spend 3X or more in engineering effort getting a distributed system up and running vs its singly-homed alternative. These days with cloud deployments (and Kubernetes for on-prem) you get a lot of labor-saving devices that make rolling out a distributed system a lot easier than it used to be. You still need to do a cost/benefit analysis!
This guy saved me so much hassle this year and it's causing a complete sea change in the way that we work. I really really want to live in a world of value-typedness and it's finally possible to do it. The simple and natural idioms are now MORE efficient than doing it the complicated way: the average function I'm writing in 2018 is significantly less convoluted and allocates on the heap far less than the same function I'd be writing five or six years ago.
You are correct, there is no safety --- you can call the constructor std::string_view(const char, size_t) and stuff anything you want in there. The main reason string_view is nice is the implicit conversions you get from the other string types. Pass in a "const char*", it finds the terminating null for you. Pass in a std::string, no problem. No boilerplate.
It's right there in the name, even!!! It's not "First Round Hugs" or "First Round Charity", is it?
This stuff isn't obscure just because you don't happen to know about it already. Chris Okasaki's publications have been cited over 1000 times, mostly for his PhD work -- those papers, especially on functional data structures and amortization analysis in lazy languages, are considered foundational for a whole research area in Computer Science.
> Is this some kind of Obi-wan Kenobi from a certain point of view stuff? Why is this so difficult to get a handle on?
Did you learn calculus overnight, or expect to understand a technical conversation about differential equations and Cauchy sequences without taking two years of classes or reading a couple of really thick books first? Why should this be any different?
> If a thing says immutable on the tin, and it's mutable, how is that purely functional? .... It seems to me that a data structure so amazing as being purely functional shouldn't be so easy to misunderstand as what we're seeing here. And it's clearly being misunderstood. And not only by me.
Sigh. Explaining it properly would involve a tour though the untyped lambda calculus, simply-typed lambda calculus and the Curry-Howard isomorphism, a discussion on denotational vs. operational semantics (Hoare logic, functional interpreters, type-preserving compilation, small-step vs large-step operational semantics, etc).
TL;DR: "purely functional" is a description of the program's meaning (in a technical sense), not its implementation.