HN user

mannyv

2,177 karma
Posts5
Comments1,004
View on HN

The important thing you need to do is specify which Mikrotik version you're using; apparently the syntax for some things changed between 6 and 7.

It does pretty well, but you need to iterate. I was trying to get it to disallow internet access for non-DHCP clients, and in the end there were so many limits to what was possible that it wasn't worth it. But it did it, and when I was testing I found them.

So like everything for best results you need to know what you're doing so you can test effectively...but it saves you from learning the syntax etc.

Modern decor has been this way since the bauhaus. Saying simplicity transcends interior design makes no sense; it is part of interior design.

The repeating patterns on carpet are an artifact of mass production.

Using Pgsql for everything shows you've been drinking the internet kool-aid. And that site is like a creepy shrine saying pgsql is the alpha and omega.

Like any tool, it works until it doesn't. And when it doesn't it takes a herculean effort to unwind it.

I looked at the first entry and yeah, just say no to moving your business logic into your database. Because change happens...and don't you want that happening in something more plastic than your RDBMS? But it's a great way to bind your solution to Postgres forever.

As an aside, I've used oracle, sybase, informix, mysql, postgresql, rdb, db2, mssql, and a few more that I can't remember. And the idea that pgsql is always the answer is the wrong answer to probably the wrong question.

Certificate expiry is less severe than an untrusted issuer or a host mismatch.

The former is most likely an administrative error (ie: someone forgot to renew, or the auto-renew is failing). The latter is more likely to be an MTM attack.

I'm not sure how you would use an expired cert as an attack vector. By loading in an old cert into an expired domain so you could spoof older content?

"nobody should be renewing their certificate within 90 minutes of expiration"

You obviously haven't worked with hardware guys.

"I mean, what's the point of those last 30 days if you need to renew it 30 days before expiration? Why not just renew it before it expires? If I'm required to renew it 30 days before the expiration date then the expiration date is a lie, isn't it?"

Your ePub Is fine 1 month ago

"Epubcheck does basic CSS checking of course, but it can’t validate CSS against a renderer which is fundamentally broken!"

According to the author, Kobo uses CSS from 2013. A quick check with an AI says RMSDK supports CSS 2.1 and parts of 3.

So it's not that the renderer is broken, it's that he believed that epubcheck actually checks against devices and the versions of CSS that those devices support.

This is exactly the issue with test tools: the test tool tests to a spec, but the platform is the gold standard. If you don't like it tough shit.

Power on after a power failure has been a Mac feature for decades. Did it stop working at some point?

Of course, it didn't work if you set your Mac to shut down if the UPS is running out of power, which was always quite annoying. You want a clean shutdown, but you also want it to come back up. I think I got around this by using shutdown hook scripts to unmount everything then just stop.

The article buries something interesting at the bottom:

"Herd size is down, but U.S. beef production is steady"

So the author talks about all this stuff, but probably the three big cost drivers are:

1. Input costs are higher

2. Possible price fixing by meatpackers

3. Lack of Mexican imports due to screwworm. Although it sounds like Mexican imports would increase the herd size, not the amount of beef on the market.

Not sure why people haven't been importing more beef. The article mentions tariff cuts for Argentina, but there are other places that export beef. Possibly the market is tight all over the world?

The only thing I can think of is to ask the AI "why this instead of that?"

Every architectural decision is a tradeoff between something and another. Every technology choice is also a tradeoff. If you understand the reasons for the choices you'll start understanding architecture.

Sometimes it starts with requirements (ie: what you're trying to do), or what your deployment environment looks like, your hosting provider, or even what technology static you'd rather use.

For example, I'd never use Java for a project ever again; it's unclear what it really brings to the table, and it's more difficult to deploy on AWS. And if I was going to use Java I wouldn't pick Spring or any other dependency injection framework because they inevitably lead to impossible-to-debug performance issues. I wouldn't use an ORM for the same reason. No Ruby as well, due to issues with migrations and active record. No postgres unless there was a specific feature of it that works better than other, due to RDBMS management overhead and inconsistencies.

Of course, now that I write this my next project is going to be some random Java/Spring/pgsql thing with a Ruby engine attached (aargh).

What helps actually is reading the "why you should use this tool" parts of each tool. You can start building a mental model/checklist of the good/bad things of each one and why would you use one instead of the other. There's almost always more than one tool available, and the way you deploy/scale/manage/backup each one will tell you a lot about when you would (or wouldn't) use it.

In general don't worry about scale until you're at the point you can test for scalability. I mean, some architectures are better than others, but all of them will be performant at 10 users. Even flat files, a bash web server, and bash-based CGIs can handle 10 users.

It's crazy that a bestseller (Grant) sold 382k copies. That's a rounding error for Mr. Beast.

Who's buying? It could be their customers were boomers, who are dying. What are they doing to bring in new customers?

The answer: nothing.

The book industry is surprisingly bad at marketing, given how big it is/was.

Has anyone else noticed the lack of free soda cups after they switched back to Coca-Cola products?

Back in the Pepsi days there were always free cups around from people that didn't like Pepsi. Now - nada.

Just don't bother with Postgres.

I've run mysql for years in production and have spent probably 30 minutes thinking about managing it. Unless there's some psql feature you need (unlikely), it'll just become a severe pain in your ass down the road because you set something up "wrong."

Just vacuuming can barf completely, leaving you dead in the water.

TL;DR: if you aren't a DBA and don't want to play one on TV don't bother with psql.

Postgres can scale, just like any database can scale.

The issue is there's a lot of lore and esoterica required to get it to scale.

Every time there's an issue with Postgres there's someone that's all "just do xyzzy, it's super obvious that this undocumented setting fixes it."

Just look at the slowdown/big pages problem.

If it works for you, use it.