ufmace

The technology being discussed hasn't actually drilled much of anything yet. Their latest press release with actual numbers[0] gives depths drilled in inches. Nice progress, yeah, but they're not anywhere near competitive with even water wells, much less the current generation of conventional oilfield drilling technology.

Geothermal power is indeed cool, but to get it usable anywhere on Earth instead of a few places where magma currents happen to be near the surface, we'll probably need several orders of magnitude deeper and wider holes than we're currently capable of drilling just for starters. Can these guys do the job? Maybe, but let's just say I'm not planning to invest in them.

[0] https://www.quaise.energy/news/from-lab-to-field-testing

That's exactly what they do. It just takes a while since there's tens of thousands of feet of drillstring.

Another thing that occurred to me after watching some of their videos - how do they plan to control rate of penetration?

Their radiation head thing has to be a certain distance from the rock face it's cutting / vaporizing, but it isn't actually touching anything. So how do they know how fast they're actually vaporizing more hole and how fast to advance?

I'm sure you know this, but for the rest of the audience, conventional drilling rigs use the measured weight of the drillstring to determine how much weight is on the bit and how fast to advance. I don't see any good way for these guys to do anything like that.

That's their idea yes, but it's only an idea, and I am extremely dubious. It's much more like handwaving speculation by people who have no experience in drilling deep wells than a practical proven solution.

They're expecting the hole to be open air, with nothing at all to push back against formation pressure. It has to be, for the radiation system to work. But that means that this supposedly fused glass wall has to withstand all of the formation pressure all the way through the borehole perfectly. And they seem to be expecting this to happen from the vaporized material just condensing on the borehole walls. One little crack anywhere, and the whole borehole could flood with water or oil, possibly even blowing out at the surface. How do they recover from that? They'd have to figure out where the failure was, seal it, then get all the water out, each of which seems practically impossible.

You can kind of get that now with the 360-degree rotation laptops, which are available with Windows or Chrome OS. I haven't used a Windows one, but Chrome OS behaves pretty nicely as a tablet.

The trouble though is, once you get an acceptable laptop keyboard and a corresponding screen, the resulting device seems excessively heavy and bulky when flipped over into the tablet form factor. You probably won't want to hold it up for more than 10 minutes.

I like the idea of one all-in-one device, but it's hard to see a way around these things. The cheesy tiny portable "keyboards" they make for tablets are pretty lame for extended typing, but better keyboards are too heavy for tablets. Meanwhile, I expect a desktop device to have the compute horsepower and RAM that are tough to get in a proper tablet form factor.

Pretty sure astronauts do too. I remember the weird astronaut love triangle incident where some astronaut lady who was in love with some other astronaut drove nonstop cross-country with apparently a BB gun and wearing a diaper to do God knows what to the guy. It was explained that wearing a diaper during spacewalks was routine for astronauts, so it probably seemed like a reasonable and convenient thing to do for her, rather than crazy and outlandish as it seemed to most regular people.

There's an easy way to put your money where your mouth is here. Just offer $11k for this or similar vulnerabilities out of your own pocket, and then resell them. If there really is a large and active market for this at higher dollar values, you'll make a killing!

Sure is funny there's nobody doing that despite so many people being so dead certain there's an active market.

I don't think "surprise bills" is a good reason to avoid AWS. Yes, you avoid them on other providers by doing simple bare-metal Linux boxes. But doing a bare-metal Linux box with no other services is also fixed-cost at AWS. You only get into tricky to determine in advance variable costs when you string together a bunch of AWS's extra services in ways that you don't understand well or don't/can't set limits on.

On the other hand, doing single bare-metal boxes being much more complex and usually more expensive is a good reason to skip AWS for simple projects. In addition to the profusion of instance types and billing/usage options.

I also think the lack of options on limiting max billing for flexible services is pretty reasonable actually. For most of them, there's no single obvious reasonable thing to do when the money hits the limit. Storage costs money too, but I don't think much of anyone really wants to have their data get deleted when the cost hits the limit, for example.

Yup, been using Kagi for pretty much all of my searches for like 6 months I think. No regrets so far, just better search results and less ads and tracking. The money is a pittance compared to lots of other things I do.

> cheaper than anyone else on the market, but not by some huge margin - half the cost or so, at best.

I feel we should point out that none of us know what it actually costs SpaceX to run these rockets. Given that they have very ambitious goals, if their actual costs were much lower, the obvious move for them would be to price their launches only somewhat lower than their competitors anyways, take that extra money, and invest it right back into Starship development.

Indeed, one would think that if there wasn't actually that big of a gap between their costs and the prices they're charging, they'd never have enough money to even think about developing Starship. I don't see any other sources of big consistent $$$ for them, and surely they wouldn't bother trying if they weren't highly confident they'd have sufficiently reliable income to take the Starship all the way through development to a successful commercial version.

It was snarky and ridiculous, yes. But then, so is the implication that subways aren't sufficiently safe due to emotional appeals to incidents that happen a single-digit number of times a year versus the millions of riders every day.

Getting rid of cars entirely may not be practical, but it is objectively true that many more people are killed and injured in car accidents in the same area over any particular length of time you could name compared to subway crime. What is the objective reason why subways are "scary" but cars aren't?

For that matter, what is the objective source for such statements as that stations are "getting dangerous enough" or that "people are avoiding them"? Is any of that backed up by actual crime statistics or ridership numbers, or just sensationalized headlines?

Out of about 3.5 million riders a day. Meanwhile, nobody pays any attention to the roughly 250 people who die in car crashes every single year in the NYC metro area. If you're so worried about safety, we should ban cars entirely instead of just taxing them a little.

It did say he was supposedly "considering" doing that, not that he actually did it.

I completely agree. I also call "citation needed" on physical keys being replaced.

It actually works quite well, if you use WSL.

Ruby itself works okay on bare-metal Windows, but virtually guaranteed any decent size Rails project will use some native gem that's a nightmare to get to build on Windows.

I'd argue that keeping Linux updated is at least as much of a nuisance.

Who is keeping a Linux machine updated without regular restarts? I've never heard of that.

Yeah, many applications on Windows update themselves. I've never seen one restart without warning, though I also don't use the windows "app store".

Meanwhile, on Linux, you often do have a package manager with packages available for a bunch of third-party software. Except the version is often years out of date. If you'd like a more recent version, the instructions for that (on the project website) are usually either to run a bunch of CLI commands to install and approve keys for another external package source, or pipe a command from a website into a root shell.

And then sometimes you end up with 20 of those extra package sources. And one randomly breaks, and you have to do a bunch of debugging to figure out why and fix it.

And then some package may either fail to initially install, or an update fail to install, due to some bug or config error, and you're stuck until you can figure out why.

The thing about metaprogramming magic in Ruby is that, it can work okay for one thing, but if you have 2 or 3 or more things all using it to do different things, it's very likely they'll conflict and blow up in a way that's really difficult to troubleshoot or solve.

Well yeah. Which shows that, despite the poor understanding of some in tech of how conventional finance actually works, it's dramatically more secure than any type of crypto at securing large amounts of money for actual users.

I think a lot of people bought some crypto early on when it was really cheap, were kind of sloppy about the security of things, and then left it alone and ignored everything while it went up by 10,000x in value. Now when their account is worth hundreds of thousands of dollars, their security is pretty inadequate for something with that actual value.

Yup. If you DON'T have this feature, you're depending on every user who has TOTP 2FA to actually save their backup codes somewhere they can retrieve ~years later or back up their TOTP some other way manually. Naturally, most users will fail to do this, so you'll have to deal with how to securely reset the accounts of people whose phones got lost or destroyed.

But then if you DO have it, you have to deal with the situation in this story, where if you can compromise their one key account, you get all of their TOTP codes too.

That's what I dropped in to say. I've used most of them, and I think Rake is my favorite.

Pretty much all of the others are shell command runners with a couple of extra bits bolted on. Well and good most of the time, but it's another language to learn, and you're mostly SOL if it doesn't support something you want to do nicely.

With Rake, you get the same basic ability to do pre-set shell commands as the others, a single one or a sequence. But you also have the full power of Ruby, a full-fledged programming language, if you want to do anything more complex.

Curious how you did deployment. On the one hand, giving him his own live server on the net seems cool, but that's a bunch more technologies to learn in order to deploy. On the other hand, seems like it would take away from the independence of the project to be like, nice work, I'll put this on the net for you.

This article is a much better analysis than anything I'd seen before about the rise and fall of Enron. An attempt to really dig into how and why it appeared to be and felt like an unstoppable rocketship of brilliance at the time that damn near everyone bought into, not just a hurr durr it's a bunch of fraud take.

https://mattlakeman.org/2020/04/27/explaining-blaming-and-be...

I suppose I can see how people are taking this piece that way, but I don't see it like that. It is snarky and ranty, which makes it hard to express or perceive nuance. They do explicitly acknowledge that "a single server can go a long way" though.

I think the real point, better expressed, is that if you find yourself building a system with like a third of the features of K8s but composed of hand-rolled scripts and random third-party tools kludged together, maybe you should have just bit the bullet and moved to K8s instead.

You probably shouldn't start your project on it unless you have a dedicated DevOps department maintaining your cluster for you, but don't be afraid to move to it if your needs start getting more complex.

What I mean here is, with print debugging, the setup is usually you have a run or test case that you start, spits out a bunch of text from the prints, and is complete in a second or two. With an interactive debugger, you often end up spending a while stepping around and through things and watching how data flows or changes. Then it can be a pain if you realize something was important after you stepped past it.

Granted, there's nothing really stopping you from using an interactive debugger with frequent short executions, but using print debugging seems to encourage it and interactive debuggers kind of discourage it.

Yeah it's a big enough pain point that I'm sure it's been done in at least some places. I'm not really sure it'd be worth the bother and memory consumption etc to set up though. Not when print is dead simple and works everywhere.

More like regular debuggers, it seems to me like it's something to set up only when print debugging just isn't getting the job done and you think you need something extra to help solve the problem.

I've used both print and proper debuggers plenty. I tend to lean on print debugging more these days. The thing about debuggers, in addition to often being a headache to set up, it usually seems tricky and time-consuming to get it to step to the lines you actually want to examine and skip the stuff you don't. And if you step past something but then later realize it was important, time to start over.

It's often faster and easier to set things up to run test cases fast and drop some prints around. Then if there's too much unimportant stuff or something else you want to check on, just switch around the prints and run it again.

This is pretty cool! I'm not sure if I'm the target audience since I have virtually no experience developing Android apps, but I'm giving it a try. It might be helpful to clarify that the intent is everything is solvable using the on-device developer tools, nothing needs an ADB desktop system connection.

That I can agree with. I think Rust strikes a pretty good balance with it though. You can still do those things if you really need to, but it has to be marked `unsafe`. This bounds the unsafety to only the parts of the code that actually need it, allowing those parts to be examined more closely to ensure they actually are correct.

I don't really agree with that interpretation. In my opinion and experience, it does not restrict architectural choices to the extent that it makes it difficult to develop greenfield projects. It's more that it rules out a relatively small subset of architectural choices which are arguably a bad idea anyways, as they do infact have flaws that may not be obvious at first but will lead to a lot of pain if the project grows above a certain size.