manv1

Ad2 -> I've run into lots of hibernate apps. They also tend to use Spring, and the team often gets lost trying to figure out which one is the cause of the problem. It's usually both.

Hibernate and Prisma migrations will delete tables if you allow them to.

Ad1 -> I'm sure they do...but usually they call in a DBA, who basically says "this is a disaster" then recommends that they refactor everything because their database schema is fucked up because it's based on some weird object hierarchy instead of RDBMS principle.

Because you're using the ORM to do selects.

I'll give you an example: prisma has a "find/findMany." As part of the build process it should examine your usage and put indexes in the column that you're using in find/findMany

Indexes are an implementation detail - but to use RDBMSs successfully you need indexes. ORMs try to hide those implementation details, but without those kinds of details you get bad performance.

Prisma just fixed another problem it had with transaction isolation levels. To even understand the problem you need to understand SQL, how databases work, and how each database implements that. It's another important implementation detail that's abstracted away...until it bites you in the ass.

Prisma also finally allowed you to use database-specific types instead of just using varchar(191), which was its default for strings.

I'm picking on prisma because I happen to be using it right now. There are good things about it, like the way it does migrations and handles schema changes. But there are times its abstractions get in the way, like when you're trying to do aggregated group by (which is easier in SQL than it is in prisma). And its migrations often fail, and to understand why you really need to understand SQL.

Hibernate was worse, because it provides a transparent object-level backing store.

Kafka was designed for places with a huge data/log volume (GB/sec or more).

From what I understand it's generally The Thing To Use when you have not very many (ie: thousands) high-volume sources that have good links. You push stuff into the logs and you can take your time chewing through the log.

MQTT was designed for shitloads (hundreds of thousands+) of small devices on bad links connecting to the mothership.

Neither of them really are a message queue. I mean, they queue messages, but they have different goals than, say, ActiveMQ or RabbitMQ (which both can be used as a backend for MQTT).

Using Kafka for a message queue is overkill. It's more likely that MQTT fits your bill.

You can notice the compression at the edges of the audio, like vocals or cymbals. Linda Ronstadt is one singer who's voice makes compression obvious - her line turns into a hacksaw blade on some songs.

That said, every system has distortion - the question is what sound do you like/want. Do you want a sound that's more forward or more laid back? Do you like more midrange? Vocals?

Audio also becomes more complicated because of hearing loss. I can't hear anything over 12-13k, so I'm sure that's affected my audio setup at some level.

It's hard to explain to developers why an ORM isn't really that great of a solution....but at a high level:

* your database is the core of your app. Abstraction implies that you don't care about the details of your data store, which eventually will lead to two major problems:

1. When things are slow you won't be able to debug it, because you're abstracted away your database and don't understand what queries your ORM is using to do things, and

2. when your ORM migration fails you won't know what to do, because you don't understand your database. In general this happens with every ORM product, ever, because you didn't put in a constraint initially because you didn't know what that meant and then you did later, which caused the migration to fail because your constraint is being violated. Or the migration fails because the tool uses some attribute and not others for drift detection, so it tries to delete your table/database because it's detected drift.

* the way you deal with data in code and in a database are different. Code iterates over objects. If you just use your ORM naively you'll end up doing some ridiculous number of selects because in code it looks like you're just iterating over objects...when in reality the ORM is doing a select/join for each one of those objects. And if you start getting more complicated there are structures that are just harder to do with ORMs...because you have to map what you're trying to do in SQL to the way your ORM works. At that point why not ditch your ORM?

SQL isn't really that hard...but thinking about how do queries is harder than you would expect. It's almost an order of magnitude faster to do joins in the database than to join stuff in-code...but that also assumes that your schema isn't screwed up, it has indexes, etc.

Lastly, a lot of ORMs don't put indexes on columns for some reason, which kills performance. You'd think that would be a detail that would be abstracted away for you at the ORM level, but it isn't. I mean it knows what you're using to select data, so it should auto-create indexes for you, right?

It's pretty amazing that a formerly public company like Twitter had such shitty documentation/processes/infrastructure.

I thought SOX mandated this sort of internal controls - after all, Twitter basically seems to be full of infrastructure risks that would (and have) negatively impacted them financially in a material way.

No key access? Why didn't they print it out and stick it in a safe deposit box, which is what a couple of startups I've been with have done...along with a couple of other key pieces of paper. Physical backup.

Cruise ships are also all-inclusive, in that they provide meals + entertainment + basic medical care. That's hard to beat.

Plus there are plenty of potentially interesting people to talk to...and shrimp. Lots of shrimp.

Just looked at the docs, it's apply and reboot which makes sense.

Oh, I forgot that you also have to manage the certs on the LOMs. Luckily browsers still allow you to bypass expired certs by default.

I wonder if you can still get into machines with the old SHA-1 stuff?

That's why serial consoles are better IMO.

Are intelligence leaks a faction trying to get the word out? Someone trying to CYA? An attempt to manipulate public opinion by essentially speaking out of both sides of their mouths? All of the above?

When it comes to intelligence stuff conclusions are more of a probability cloud. Everyone is lying, so the question is which scenarios are more or less likely?

Instead of COVID let's take Lyme Disease as an example. Lyme Disease is named after Lyme, CT, where the stuff was first diagnosed/discovered. That's interesting. What's also interesting is that there was a biological weapons research facility across the Long Island Sound from there.

Well, if you didn't know anything else about Lyme disease it wouldn't be a stretch to believe, at some level, that the origin was some kind of bio weapon that escaped. New disease near a weapons lab? Sounds within the realm of possibility.

Now you add some more information: namely, that Lyme disease is a worldwide problem, and they've been found in ticks all over the world. Well that makes the lab origin theory substantially less likely (probably 0%), because it's unclear how ticks would have spread to Asia, Europe. Nobody is going to go around infecting ticks as a bioweapon.

So your analysis really comes down to how much information you have. You have a bunch of guys walking around randomly, not a big deal. You have a bunch of random guys meeting in random places really often, well, maybe that's something that needs to be watched.

I've never heard of AWS suing someone to keep using their services.

I wouldn't be surprised if Oracle or any outsourcer did that...but that implies a breach of contract, not a transition after a contract is done.

IBM sells mainframes because they're impossible to replace due to the way they're used. Those big printers that print financials statements apparently don't talk to anything else (funny, I was just talking about those the other day). It's about I/O and throughput with those things. You'd think someone would have come up with a replacement, but presumably the market is so small that nobody cares.

I know what DRACs are (it's Dell's LOM). I asked whether the DRAC bios stuff required a reboot.

Do they need a reboot to take effect? I haven't touched a LOM in more than 8 years!

"We could run our entire production system in a half-rack for about 10% of what we pay AWS"

It sounds like you should make a business case. 90% savings is a big deal, unless it's the difference between $1k and $100.

Let's face it, fear of vendor lock-in is almost always bullshit.

Everyone's locked into a vendor at some level or another. Want to move off of Oracle? It's work. Want to move off of servers and into VMs? It's work. Do you want to move off of some Java library like Spring? It's work. Even moving from apache to nginx is work (assuming you're not just serving static files).

Your technology choices always lock you in. You can minimize the cost of moving with architecture, but there's only so much you can do.

The key isn't avoiding vendor lock-in, it's understanding what the tradeoffs are for that lock-in and making sure it's a decision instead of a by-product.

It's like writing your stuff in NEW_TECH_LANGUAGE. Sure it might give you better performance, but now you have a bunch of deployment and maintenance headaches, and your people will cost more and be harder to find. And does it even work/scale in production/HA? How do you monitor it? What kind of weird runtime things are you going to get abused by?

One interesting question is: if you started today, would you be able to afford boxes that cost 60k? Or would you do your software some other way that doesn't require 2TB of RAM?

Obviously when you started your stuff didn't need 2TB of RAM. If I read your history correctly I don't think you could even buy a box with 2TB of RAM back then. That's enterprise grade hardware, which today costs a fortune. Back in the day it would be a bigger fortune.

Instead, you probably started the way everyone else did, with maybe a 4GB or 8GB linux box at home then built things up from there and a bunch of curl scripts and a local instance.

So why the resource requirement? An in-ram database?

Mainly curious.

Well, it depends on the colo.

I mean, it's not like a colo doesn't have issues. At one point our colo was running some cable and we discovered that their cables to our rack were wiggly...after our stuff went offline intermittently. That was hard to track down.

And you need to set up the LOMs, the management network (hey, you don't want that on the public internet), VPN, serial cables (backup to network LOM), maybe a load balancer. And you have to hope that when you reboot the box it doesn't fail POST. And you have to remember to turn off power saving in the BIOS (how many people forget to do this?). And you have to set up the RAID 5/10.

And you have to do this sitting on the floor, because not a lot of places provide chairs in the racks. Oh, do you have a rack-mounted KVM/monitor/serial console or are you using your laptop with a serial cable to do all this?

I mean, it's not hard, it's just a lot of detail work. And I suspect that these skills are going away.

The thing is, his TCO would include training, rebuilding their existing processes and procedures, and having to run stuff in parallel for a while. That's not including a re-architecture and the impact it would have on their stuff today.

Sometimes all people need is a big box in a data center. Management of the environment is already a sunk cost. The hardware is already expensed. They don't care about scalability/DR/etc.

From a hard dollar point of view staying colo makes sense. Plus politically they don't want to do it, which is really the only point of view that mattered.

If they needed to have actual DR then the numbers would be different.

It's good they did the math. AWS doesn't fit everything.

Really, the main things that cost actual money in AWS are memory and CPU (that's including elasticache, RDS, etc). Bandwidth can be negotiated away. I'm sure you could do some kind of super deal on CPU/RAM, but we've never bothered.

Would it be worth it to rearchitect your app so it doesn't use 2TB of RAM? Probably not. You have a lot of sunk costs, and redoing everything will probably break everything. You guys are big enough that CapEx doesn't matter that much. You just need big boxes with lots of bandwidth.

If you're happy with what you've got, stay with it.

An API is an API. The code behind it being closed is irrelevant.

a paper in video format?

I actually hate videos, it's easier for me to read than to listen to someone taking 5 minutes to explain a paragraph's worth of stuff.

"It's longer because monetization."

For reference, here's the current spec...all 833(!) pages of it.

https://www.ecma-international.org/publications-and-standard...

"when I see it in a code base I won't be so confused at least"

When I first started using node way back when I discovered all kinds of idioms in use that I had never seen. It was a confusing few weeks for sure.

"The only programming languages that people don't hate on are the ones nobody uses." - someone online

Negative indexes might actually be useful.

At some point I actually need to read the actual language specs, I guess.

Activists really tried to push too much crap into the pile of "net neutrality."

There were at least a few different issues in the NN bundle:

1 against preferred ISP access 2 against content-based ISP restrictions 3 against charges to upstream content providers based on traffic 4 against paid prioritization 5 no change to the current peering models

Most of it was IMO total bullshit. Having worked with ISPs, I can tell you that they have no real interest in being content police, prioritizing specific services, at least in the US.

Their real interest for ISPs was making large sources of traffic pay.

This is going to conspiracy theory land, but IMO a large part of NN was the content providers (YT, google, facebook, etc) manipulating the public into supporting some bullshit law that prevented them from having to pay ISPs for the downstream traffic they generate. And it's a lot of traffic...and billions of dollars in advertising revenue.

All of that was wrapped up in the typical "call to freedom" that is the equivalent of "it's for the kids."

Headline was a bit shocking

One could say that, given the market share, that the vast majority people don't care a whit about open and verifiable hardware.

Use a 2FA app that backs up to iCloud or syncs to another copy of itself somewhere.

Google authenticator is great, until it wipes out all your entries. It did that a few years ago for reasons unknown, so I moved to 2STP (which is now unavailable).

Also, the app you use should have an apple watch app, so at least if your phone dies you can use your watch to authenticate.

They don't care about the facts, they care that he's using a different OS on his phone.

And they really don't care that much. If he really wants to he can say that it's because of his big dick.

"What’s more, Gen Z’s older friends and colleagues, the millennials, do not bring with them the messages of hope they inherited from their Gen X forebears"

Messages of hope from Gen X? What is this author smoking?

So what you're saying is that the 8086 was sort of stack based (like forth), and a given instruction just consumed the number of bytes off the stack it needed, then the assumption was the next thing on the stack was the next instruction?