throwawaaarrgh

They did use metal fasteners, just sparingly, because iron was expensive and often of poor quality. Later on even when quality and availability improved, laws were introduced to limit the use of metal fasteners, largely for political and economic reasons.

One of the big factors in wood selection in Japan is rot and insect resistance. Japan has very high humidity and buildings were open much of the time, demanding resistance to mold, termites, etc.

Another big factor was time. Fast growing species allowed quicker processing, which was helpful considering Japanese buildings have historically not been built to last. Some do last a long time, but most famous Japanese buildings have actually burned down many times, sometimes dozens. Edo (Tokyo) was well known for basically the whole city catching on fire fairly often.

They did use hardwoods, too, but where hard wood was necessary or useful, like in certain beams or components that needed hard wearing.

Adding more layers can add context, which can improve communication, which solves (or at least improves) the problem of conflict arising from poor communication.

If everyone could agree on behavior in a common space, we wouldn't have politics, or even government. We would just all agree on something and then go about our lives. Internet moderation is just governance for the private sector.

That's the fallacy. That keeping it all in one place with one tool is somehow better, because you can, or because it's all tightly coupled, or because it's one less piece of software. But in practice it just creates more problems (lots of them) that a dedicated, separate queue does not have.

If you want a very simple way of looking at it, think about how code becomes modular. You don't put all your code in one function, or one class, or one file, or even one application. Not just because it's easier to read, but because specific components should have clearly defined delineations from others, and forceably be kept separate at the borders of their functionality. Doing that leads to benefits that outweigh them sitting next to each other, tightly tied into each other.

At the very least, you should not be using one giant database for all your data in all your applications. Everybody should know that by now. And just like you shouldn't conflate different applications' data containers/interfaces/internals, you shouldn't conflate a queueing system with a completely separate data container. They need to be separate to avoid a bunch of problems. Again, not because you can't do it - like keeping all your code in a single function, or class - but because it's going to lead to a bad time.

The idea that "performance" is the big problem, is the same as saying "performance" is why you don't use an IMAP server as a queue. Hey, you've already got an email server somewhere, and that means it's simpler, so that means it's a good idea. Based on the logic in this article you should be using your email server as your application's general purpose queue.

I feel so bad for the poor engineers that will believe this crap and later regret it. If you're going to advocate doing something like this, you should be forced to be honest and explain all the reasons it's bad idea. The fact is that people are lying about the problems of using Postgres as a queue, because they just don't want to believe that the world is really more complex than that.

It's not an either/or. Many business both own and rent things.

If price is the only factor, your business model (or executives' decision-making) is questionable. Buy only the cheapest shit, spend your time building your own office chair rather than talking to a customer, you aren't making a premium product, and that means you're not differentiated.

This guy gets it, I agree with it all. The exception being, use Fargate without K8s and lean on Terraform and AWS services rather than the K8s alternatives. When you have no choice left and you have to use K8s, then I would pick it up. No sense going down into the mines if you don't have to.

Daily stand-ups are wonderful and need to be encouraged.

I'm gonna need a decaf option

Not worth 3rd party vendors with basic SSO. They have no idea when the user leaves the company because there's nothing updating the vendor's sessions.

I'm still flabbergasted when a company lets me index their entire AD tree as a random (or, holy crap, anonymous) user. Very nice of them, but still.

It's also often the only way to get information that doesn't exist in an Intranet page, like, literally what teams are there in IT, where are their offices, who's somebody's manager, and of course, what distribution lists am I not on that some other user is on that's causing one of us to have issues accessing some internal company portal.

There's a very common problem with systems that use SSO, where the 3rd parties that accept SSO logins cache the login information, sometimes indefinitely. A user can leave the company but their login placeholder account stays in the 3rd party, and active login sessions are maintained basically indefinitely. So you can leave the company and lose your AD account, but still access the 3rd party. As Rachel says it's kind of a hard problem to solve (but not that hard).

This is like making lock pick sets illegal to carry unless you're a licensed locksmith. Didn't really stop criminals from getting or using them.

I'm not stepping back from anything. Plenty of critics have hated films that end up being cult classics. A critic is no substitute for individual sensibilities. You can defer to them all you want, doesn't mean it's a great way to develop culture. But it is a great way to develop an insular culture.

So how come I've seen so many great movies at film festivals that no critic writes about?

Actually sounds like a good thing to me. Any organization that styles itself an industry taste maker is simultaneously repressing the organic creation of culture by the disorganized masses.

Culture is best discovered by accident, and considered on its merits by the individual. When some critic tells you what's good and what isn't, you'll never know if you actually like it, or you just like it because someone told you you do. Simultaneously, if that's your only outlet for finding culture, you'll miss all the rest.

It's like with movies: you can watch whatever trends on Rotten Tomatoes, or you can watch a whole bunch of random stuff at a film festival. Guaranteed you will find something at the festival that will never trend on RT but that you'll enjoy thoroughly.

Good advice doesn't stop being good just because people stop following it. Ultimately success is a matter of effort.

If you twist yourself into a pretzel enough you can make Bash do all these things. Doesn't make it a good idea.

The biggest problem with depending on Postgres is it's a large complex monolith. Any problem you have only has two possible solutions: 1) spend a ton of time trying to twist yourself into a more pretzely shape to get it to do what you want, or 2) replace that thing you wanted with some external thing.

Both of these waste valuable time on something that isn't providing any business value. They also are entirely preventable/avoidable, by simply not putting all your eggs into one basket.

Basically the whole "just use Postgres" philosophy boils down to: I don't want to learn new things, and I just like making things from scratch with custom code. That's great if you're an engineer and you want job security. But it's bad strategy, engineering, and use of time and resources. Anyone who approves of using Postgres in this way should not be in charge of engineering decisions.

If your machines are all hypervisors you could migrate important VMs to a couple hosts and turn off the rest. You could also possibly throttle the vcpus, which would slow down the VMs but allow you to run the machines cooler, or more VMs per machine. Finally the ones with long running jobs could just be snapshotted and powered down and restored later, resuming their computation.

There's a reason us old fogies were so excited when virtual machines got increasingly robust. We could use them to solve problems quickly that used to be nearly impossible.

I have always hated the secret parties. As soon as I found out about them, I set about infiltrating them just to fuck with them. One of the reasons I left the hacker community was the toxic elitism and posturing.

The same reason any other gaggle of degenerates are allowed in Las Vegas: Money.

The only food worth the trek is the Toxic BBQ

Getting old rocks, I highly recommend it.

"Early stage" anything doesn't sound very good either

Christ I'm old. I still remember when it was at the AP. Although I've left that part of my life behind, I'm glad DEF CON is still around.

¿Porqué no los dos?

It is insane how reliable landlines are, though. When the power goes out, you can make "candles" by connecting a 0.47 uF capacitor to a LED leg and connect both ends to the red and green phone wires; there's enough voltage to power a couple of them without the phone going off the hook.

In an emergency, the lines don't get clogged like cell phone towers, and the Telco infrastructure is much more protected than wireless (you'd have to bomb a pretty big building with no windows to take out a small area's lines). It's probably fine in the grand scheme that we lose these properties. We'll just reinvent them later if it turns out we miss them.

Man. I really wish we didn't have language discrimination. Perl is just so fast to write and has such a sizeable ecosystem of modules, and such great docs, that I can produce any program in Perl faster than I can write it in Python, purely because it's more expressive in a smaller space and has fewer restrictions. But no team I'll ever be on in my life will agree to work with me on a Perl project, because everyone just "knows" Perl is taboo. People laugh at me when I suggest using it.

Yep. The HN users see is highly curated. Mostly by algorithms, sometimes by humans.

No company can survive bad management. One shitty exec that says to do X. Everyone has to follow and the results speak for themselves.

I wonder though, for public companies, do employees not have the obligation to refuse certain demands in order to protect the shareholders?