vandahm

I've never submitted anything to HN, but I think they want you to use the original title of the article, which is what the submitter did.

Honestly, if I was asked to choose between a 10% raise or a cubicle, I would take the cubicle in a heartbeat.

I didn't study physics in university, so please forgive this naïve question. Would an appropriate interpretation of quantum physics simply be that we don't have an interpretation of quantum physics? We have mathematical equations and observations that confirm the math, but it seems that we don't have observations that give credibility to one interpretation over the others. Instead of speculating, can't we just agree that we don't know?

I'm not suggesting that we should do that -- I suspect that there's a lot that I'm missing. But I guess I don't understand why these speculative interpretations are so alluring if we can't confirm or invalidate them through experiments.

This is great! I can remember how painful it was to figure this stuff out when I was a student. Even with what I know now, I still learned a few things from browsing through the material.

Why not?

I don't play violin, but I play guitar and have built guitars. There has always been a lot of magical thinking about vintage guitars (and the very specific species of rare woods that they are made from) that just doesn't seem right to me in my experience. It doesn't surprise me that the same thing happens in the violin community.

That said, I'm glad that these historical instruments are so carefully preserved. Violins are very delicate, and to compensate for that, they designed to be almost infinitely repairable. But that only happens if they are perceived to be significant enough to justify the work.

Cesium-137 is made in nuclear reactors, but some radioactive isotopes with shorter half lives (well, short compared to the age of the Earth) exist in nature because they are a product of the natural radioactive decay of other, long-lived materials like Uranium.

And yet, think of all the servers that get hacked today because they are running unpatched versions of their operating systems. I agree with you that there were lots of CCTV systems 30 years ago. I'm just pointing out that the fact these cameras exist doesn't mean they are maintained or that employees know how to use them, and that this problem was more challenging in the past because stuff was mechanical and analog and not as easy to automate.

Security cameras existed, but they very frequently didn't work. One of my college professors was murdered in a bank robbery around 20 years ago. The bank technically had cameras, but they didn't work and no one bothered to do anything about it. Consequently, there was no recording of the robbery and the police chose not to investigate the crime.

Even before its current troubles, I'm pretty sure that Twitter never brought in the kind of ad revenue that Facebook enjoys. Twitter desperately needs its advertisers to survive, but those advertisers can easily survive without Twitter. That puts Twitter in a tight spot.

Beyond that, Twitter does need to keep news organizations engaged, but Musk is driving them away by banning a lot of the journalists who work at those organizations.

Maybe I'm looking at this from the wrong perspective, but I don't see how Twitter is going to recover from the trajectory it is now on. What would it take to repair the damage to its brand or to get advertisers to return en force?

At any rate, I've been quite happy with Mastodon as a Twitter alternative. It has the same vibe that Twitter had in the old days, and I was pleased to see that most of the people I joined Twitter to follow have already made the move.

Hey, it was the 1950s -- why not double down on cancer?

> there is no one reason why we dont have basements, but it is more likely to do with the fact that up north they have to dig deep (3-4 ft) for the frost line. If you are digging that deep anyway, you might as well go an additional 4-5 ft and build a basement.

In Minnesota, where I live, basements are definitely a byproduct of structural requirements. You have to dig 48 inches so that your foundation is under the frost line. But also consider that you don't want your front door to be at ground level, because then it might not open after a massive snowfall. So if you add up all that vertical space, you get about 7 feet, which is about the ceiling height of an unfinished basement.

I can only speak for myself, but even though I am very skeptical of DeFi and crypto, I don't look down my nose at people simply because they see it differently. I do look down my nose at people who are deliberately running scams, but it doesn't sound like you're doing that.

I think there's a dark side to most things, and that in the beginning it's not easy to see what it is. For example, I think that social media can be destructive to society and to individual people in a variety of ways that weren't at all obvious to me when I was younger. I don't think it was bad to believe in it, though -- it did, in fact, make the internet useful and accessible to way more people, and that's probably a good thing in the long run, even with all the problems that come with that.

In the worst case, you'd have to tell a future employer, "I went to work in DeFi because I believed in the potential of the underlying technology, but [IT DIDN'T WORK OUT || I DON'T BELIEVE IN IT ANYMORE] and now I'm ready to move on." That sounds pretty reasonable to me?

You don't see this every day:

https://github.com/dspinellis/unix-history-repo/blob/Researc...

Is this B, or is it BCPL? What would have compiled this code back in the day?

That's a lot of finger gymnastics, but it's probably better than `pbpaste|pbcopy`, which is how I've been doing it all these years.

That was the best computer I ever owned. I used it every day for seven years, long after it was obsolete.

I like having a separate physical and psychological space for my personal and professional lives, and remote work deprives me of that. I like having the freedom to work from home, if I'm expecting a delivery or there's a problem with my car. But after working from home for an entire year during the pandemic, I'm ready to get back to the office.

What's the best way to incinerate a `pom.xml` file?

I do the same. The people I blame for bad service are always outside my reach.

I used to be a software engineer at a nonprofit that handled a lot of customer care requests. I wanted to see what frustrated our users, and I also wanted insight into how we could better support the customer care team. So I talked to the volunteer coordinator, took a day of PTO, and worked a shift in customer care. (Because I did it as volunteer work on PTO, my boss and project manager couldn't tell me not to do it.)

Reader, working in customer care blows. It sucks hardcore. From my engineering work, I actually knew what the cause of the problems were and understood the timeline for fixing them -- information that real customer care reps rarely have available to them, but even that wasn't enough to appease some people. Even when people weren't rude, just the never-ending barrage of complaints and problems that I had to fix wore me down. And I only worked one shift, and then went back to engineering the next day.

People who can do this day after day, retain their composure, and somehow not burn out from the nature of the work are awesome, and they have my respect. Their jobs are absolutely more difficult than mine.

I wish I could work on these magical projects that people with blogs work on, in which everything works like it's supposed to do. In my experience, though, it's not unusual to be forced by management to migrate to a new RDBMS a year into a project. The last time it happened to me, we were using Rails and had very little difficulty migrating from PostgreSQL to MySQL. We didn't need to alter application code or rewrite tests and only had to manage config changes and migrate the data. I imagine the transition wouldn't be much different if we had been using Django.

I don't have anything to contribute to the greater discussion, but I just wanted to thank you for building your app and sharing a link to it. Making labels isn't something that I often do, but when I have to do it, I need to make a lot of them, and that's always a pain. I'm going to give your solution a try as soon as I get off of work.

> "on computers you preferentially use base-10, even though said computers are going to store the values as base-2?"

I don't understand this comment at all. Most people are not computer programmers and therefore have no insight into how computers represent numbers. They just populate text fields in Excel, or whatever, with numbers. It's easier to use decimal points to do that than fractions.

When I'm not using computers or calculators, I do prefer American-style fractions over decimal point representations. Fractions are a lot easier for me to manipulate in my head. If I'm out in my garage, upside down, underneath a car, and trying to decide which drill bit to use, I don't have convenient access to the calculator on my cell phone or a pencil and paper, and reliable mental math is important. The fractions are easier, so that's what I want.

To me, this reads like an argument for a serverless architecture and not a discussion about VPCs themselves. But that's not always on the table. Even if a serverless architecture is better for some use case, if you have a traditional application that already works, it's inconceivable that setting up and monitoring the VPC is more effort than a massive rewrite to go serverless.

At work, we have a Terraform module that receives a few input parameters and generates a VPC that complies with all of our corporate security guidelines. The module isn't complicated, and it ensures that we get it right every time.

We do this for every commonly-used AWS resource -- S3 buckets, SQS queues, etc. It eliminates most of the risk of misconfiguration, allows our infrastructure changes to be code-reviewed and unit tested, and eliminates a lot of the fiddly crap work associated with setting up something on AWS.

I do some volunteer IT work for the nonprofit makerspace in my town, and I obviously don't have access to my employer's tool chain if I have to work in their AWS account. It really is a night-and-day difference.

FAAN.+G

How does the microcontroller know the state of the cube?

In Brazil, in the 1980s, a couple of burglars broke into an abandoned hospital and stole a supply of cesium chloride from a radiotherapy machine. The difference between your scenario and this one is that the thieves didn't know what it was -- it just looked important and expensive. The whole thing was a huge screw-up, and a number of people -- including one of the burglars -- died from exposure to radiation before the authorities sorted it all out.

    https://en.wikipedia.org/wiki/Goi%C3%A2nia_accident

In response to Question 2, here's the best I've got: At a previous job, we used MongoDB with a write concern of 0 to store logs in such a way that we could more easily search through them later on. The information we were logging was useful to us as developers but wasn't critical to the business, so we were willing to take some risks in order to achieve faster inserts.

It worked OK for us at the time, but if I had to do it over again today, I would probably look at ELK before rigging something up with Mongo.

In the larger sense -- at least for conventional web stuff -- I don't like Mongo. Usually, I'm building something that receives a web request, reads or writes to a database, then generates either a web page or a JSON object as a response. In theory, since you know what information you need to render the response, you should be able to include all of that into the structure of your Mongo document, then fetch everything you need with only one query. In practice, however, business and UX requirements tend to change quickly enough that it isn't feasible to do that. As your product evolves away from its initial design, it gets harder to bridge the gap without joins and transactions. At that point, at least for me, I just feel more comfortable using PostgreSQL.