mikst's comments

First, you should find out exactly what is happening. Coroborate what he is saying.

Assuming things are as you say, fist thing is to teach fear management. Do light fear training. Nothing extreme, ideally something tailored to his psyche. Without this nothing is gonna work.

Then, teach him crowd control. I'm not joking. There is science on how to deal with a crowd. You don't need to explain advantages of Android, but how to use them to stand up to those kids.

Both of these skills are universally useful, and will help him in life almost guaranteed.

The general problem with starting with desired result and working towards the implementation is that there is no guarantee you will find solution.

Not all desired results are feasible or possible even.

Maybe people simply have different spending habits. Personally I try to stay away from "pay as you go" businesses. Moreover, I try to pay for the year upfront if I can help it.

Purely psycologicaly I think it's an attempt to take control of your future, you know? Reducing uncertainty is more valuable then many things... "The best way to predict the future is to make it" and all that.

Like, if I'm not sure whether I'll need it and how much of it I'll need, there is something wrong and I'm not gonna buy it at all.

First, everything is a tradeoff. Do not expect to have a cake and eat it too.

Secondly, thiese are indeed two different levels. A database that serves as a single source of truth can be implemented as an entire cluster of serves with no single point of failure.. At least in theory ;)

You need to check for empty files

find ... \! -empty ...

they have the same hash, but they do not need to be treated as duplicate

one way to understand how to break things is to first build a couple

when you build things you can understand the trade-offs people have to make which gives you an intuition for weak spots

Can we just call it "The Hackening"?

Pretty Please?

You are not wrong, but All Economics is like this.

A "law" in Economics is supposed to work over infinite amount of time, over infinite amount of participants and so on. Technically they are not laws, but idealised long time trends.

Obviously they do not work exactly in real world, but that doesn't mean one should dismiss them entirely.

Apple due to it's market positioning has to put the most powerful cpu available. They weren't able to cool it though, so it was constantly throttled down, which is inefficient because you have to pay for the whole thing while you can only use 70% of it.

Now they put weaker chip but it can be utilized to its full capacity, so essentially at the cost of capital expenses, they significantly cut per laptop expenditure. Also internalizing more r&d helps with taxes.

I don't know whether potential instructions set optimization will yield that much, because Mac needs aren't really different; maybe they will focus on battery life more then other laptop manufacturers, which they historically did, who knows.

Face it, software is judged by amount of recent commits. You can't have lots of commits if you build right from the getgo. Therefore "software built to last" is doomed for obscurity.

I think because it's much easier to do deploy templates than multitennancy.

If you don't know what you need, what chances do you have to make a right decision, especially talking to people who are interested in selling you stuff?

I don't see how there is any alternative to researching stuff first in order to know what you need, especially if we are talking about "efficiency" and "value" which are not rigorously quantifiable.

I think we picture "high output team" differently.

The way I see it, a "high output team" usually knows all the tools in their respecive field, and knows 99% of them are trash and this fundamental thing has to change before a better tool becomes possible. Which in turn makes conversations with salesmen mostly pointless.

On the other hand not a "high output team" don't know exactly what they need and just chase hype.

Could you share what kind of data points you use to describe "broken and convoluted processes"?

> IT/engineers won’t spend time building and maintaining email servers, we’ll spend $5/month/employee on G Suite and use their time on things that make our products more valuable

In-house email servers are not constrained by the time to build them, but rather by reputation/spam considerations. Sorry, but that's a lucky guess ;-)

> paying for a third party SSO solution for our products and instead using engineering time to build first class integrations between our products and complementary products, because having an artisanal SSO System doesn’t benefit our customers

That's one of vendorlockiest vendor lock out there, which is a very YOLO decision.

The idea that buying stuff is more efficient then building it yourself is at the cornerstone of the modern economic theory, but that's only a theory. In the wilds there's much, much more factors to consider then just comparing cost of building versus cost of buying.

In short, if you pay "technical" money, you _will_ find such a person

---

IMO, it's not so much technical people don't like doing support, it's just bad for career. If you can solve that for your potential employee you're good. But that is gonna be tough because you can't influence other 99% of employers who treat support like trash, making it unattractive for people with technical skills who have the choice. On the other hand some people are fine with what they can take right now and do not bother too much with the whole "career" thing. If you can offer attractive paycheck for a sufficiently smart person, you will find your 2 in 1 support.

I dunno, I have a filter in my brain - I can usually pretty accurately detect marketing content in a first second looking at it and stop paying attention to it.

Just remember all that "fluff" is what pays the bills.

The Internet is a network of networks. Among those networks there isn't any central network. That is what "decentralized" is supposed to mean. And while some networks are more prominent then the others the Internet _is_ decentralized.

Services that work atop the Internet are what they choose to be. For one centralized services are easier to code and easier to monetize, so not very surprisingly more people choose to build centralized services.

mm.. RDP?

Hi, I don't use budgeting on a regular basis, but when I need it for a project or a trip I use ledger-cli.org

It isn't a "batteries included" solution, but with a little creativity it allows you to do pretty much anything you want.

If you are prepared to even build your own app, I thing it might interest you.