cathartes

> Good managers are invisible geniuses who know how to fade into the backdrop, get out of your way, allow you to make decisions, and do not feel fear that they have to micromanage or create empty superficial artifacts to justify that they are working.

I feel like this book discusses exactly the kind of Good Manager you are talking about: https://www.amazon.com/Turn-Ship-Around-Turning-Followers/dp...

But she was explicit in saying no one even asked if anyone was watching. Instead, each person in succession walked in, recoiled in horror, and decided to flip the channel without a word. One person doing this is unexceptional. Two? Less than chance, but possibly coincidence. Three or more, however, suggests a gestalt of in-group sports dickery existed around her.

I think what's more unsettling to me about that part of her story is that there was only One Right Answer: the sports game. I'm accustomed to team dynamics with aggressively asserted opinions; but even within the group, those opinions generally differed by substance or degree. Faced with this kind of consensus, I'd feel alienated too; because I know this behaviour would be integral to my daily work interactions with those people . . .

The author's point about "dogfooding" jumped out at me more than he probably intended, but that's probably because it's an aspect of Slackware's SlackBuilds repository (SBo) that I can't say enough about.

Quite often, SBos are maintained by folks who use (even depend) on the software they are responsible for. As such, well-tested and sanely configured software tends to be highly valued by maintainers, and package responsibilities will commonly change hands when a maintainer no longer uses what (s)he's responsible for.

The mechanics of an SBo are also dead simple, making package review and modification by the user straightforward. This means that rolling your own package is straightforward, enabling you to easily become a "dogfooding" maintainer yourself for any package not already in the repo. Few distributions allow ordinary users to close the official package loop with anywhere near the ease--both technically and bureaucratically--that SBos do.

SBos are not the Perfect Package model by any means. But in terms of "dogfooding", ISVs and big distributions (especially Canonical) could stand to learn a few things from a relatively unstructured community of volunteers with a taste for the KISS principle.

Doug's message brings to mind Chuck Moore, the creator of Forth, who is probably as fierce a "negative" coder as anyone has ever seen, and he extended his approach similarly to his stack-based hardware. Sadly, Forth (in any guise/implementation) has been largely written off by the world, and is probably better considered a divergence in evolution from today's computing trends. But I think the lessons it teaches remain relevant today--its minimalism, similarly "born of a taste for achieving big power by small means rather than by unbounded accumulation of facilities", is breathtaking, even if Forth is no longer quite practical to use in many of today's software/hardware ecosystems.

I see overlap between these approaches, but not sure I'd go so far as considering one or another "better" for all use cases. Tails specifically targets "less sophisticated" users, and is pretty self-explanatory. And true to its name (and unlike Qubes and Whonix), Tails goes to pains to be "amnesiac" by design, although you can of course subvert that by enabling persistence. It's hard to hold a candle to Tails when using computers at local libraries or internet cafes, or when you really need to maintain a minimimal data footprint when traveling internationally.

If the millions you are surrounded with are living exactly the same way, then yes--there is no challenge. But to make options or even omit things that are widely considered staples by your peers, to put yourself at even this much of a cultural disconnect from those around you, I do think there's a challenge in this.

Why the cynicism? I don't get a "holier than thou" vibe from this article at all. To me, it reads as a simple progress report about one person's trial in embracing something other than consumerism to fill emptiness. I think this individual should be congratulated for even trying.

What I find strangely absent in most discussion of the UBI is how these fixed payments will hold up against inflation. Even simple arithmetic based on the Consumer Price Index over the past forty years will suggest that an amount like $10,000 US in 2016 dollars will likely be trivial cash in twenty years time. (And, arguably, it's already trivial cash today for just getting by.)

More than likely, the UBI will have no lasting impact, no matter how it is implemented, unless the buying power of the dollar is realistically accounted for in each year's handout. And I just don't see that happening.

Simulations, including those that use Monte Carlo methods, might be one class of examples.

Even in power plants, Windows tends to be the rule rather than the exception. The wind, hydroelectric, and solar facilities I'm familiar with run entirely on Windows, right down to the SCADA and process control systems.

Living and working in rural locales will leave you with the feeling that many software developers assume you've got the same fast, unlimited connectivity that they have. For users like myself, with each forced batch of updates you can almost hear some well-connected urbanite scoff about pilfering "only" a few extra gigs from your connection, this week. "They won't even miss it!", they muse. And for the average user with metered connectivity, that's probably true--until the bill arrives. Or, like in parts of Africa or eastern Europe (where account usage is typically prepaid), when your data quota for the month maxes out (== connectivity loss) hours away from the nearest company service desk or kiosk within a week of topping off your account and barely doing more than checking email. Unlike me, however, very many people so afflicted by second or third world connectivity don't have the luxury of not using Windows . . .