abhibeckert

I agree - the authors of this paper don't seem to know anything about how rope is made.

Having said that... the tool does look like it could be used for processing and weaving fibres together.

As for "making a rope in 10 minutes"... why would anyone do that? A good rope is a multi-purpose tool that can last a very long time. You'd invest days in it, not minutes.

On iPhone, bluetooth is presented to the user as a location check. Big data companies will if you're near your toothbrush then you're at home. And they can figure out where "home" is by other tracking methods.

"Bad" and "un-performant" are relative terms and as your company gets bigger, you're increasingly more and more likely to have colleagues who write even worse queries than an ORM would.

For example I've encountered queries that are not only slow, but they generate several hundred megabytes of output all of which is sent to the user's web browser where JavaScript selects the relevant two kilobytes of data to show the user.

The worst I've ever seen was a system where every single write to the database would be sent to every single web browser viewing certain webpages. 99.999999% of the writes were completely irrelevant and javascript in the browser would simply disregard them. The server load was immense... and eventually our Sysadmin brought it to someone's attention. Where we found out it was leaking sensitive data.

Agreed. I would offer a PDF version of the project's readme file as a demo.

OP: this is important. There are a million tools to generate PDF files, most of them don't produce nice looking PDFs.

> Every proton would have the energy of a baseball

I wonder if you could capture that energy and use it to generate thrust.

Most of the energy is coming from your thrust so it'd be a lossy process however if you're able to capture all of the energy then there won't be anything left to damage the ship.

The title of this post is wrong.

This isn't about the 737-MAX, it's about a new sub-model which currently only exists as a prototype and is undergoing a lengthy test and certification process.

AFAIK it's scheduled to start passenger flights end of this year or year early next year and this specific issue might have no impact on that.

Fujitsu's didn't prosecute anyone or send anybody to jail. All they did was write software that had bugs in it.

If you look at the version history of any software, you'll find it's full of bug fixes. Writing software without bugs is literally impossible. It's incredibly complex and written by "actual real people" and that means there will be mistakes.

If those mistakes lead to millions in liability, then you're going to have to start paying me those millions upfront, before I write a single line of code.

It's the same with a CEO - if people are criminally liable for mistakes made by people working under them... then nobody's ever going to accept a job where they delegate work to other people.

The solution to this issue is not to attack people who made a mistake. It's to put systems in place where you check for mistakes. I guarantee you the jury and courts that found these people guilty were presented with "facts" such as "nobody else can remotely access the software" which, it turns out, were total bullshit. The people who presented those facts in court are the ones to blame for this. They clearly either lied or made assumptions.

Both of those are serious crimes. You don't say anything in court unless you actually know it yourself. If someone else tells you something is true, you don't repeat what they said. You bring those people in as an expert witness to talk to the judge/jury directly, under oath, and you tell them not to make any assumptions either.

There should have been millions spent on a full code audit done checking for bugs in the software before allowing it to be admitted as evidence in court.

They're not that hard to extinguish, you can just wait for them to stop burning on their own. Which is generally how car fires are also extinguished. The good news is EV fires take a long time to burn through the fuel, allowing anyone in the vehicle plenty of time to safely get out of the car.

Sure, it's a bit annoying for the fire fighters who turn up 20 minutes later... but I think even they would rather arrive to find a burning car if it means the people who were in that car are safely watching from a distance.

I actually kinda like the fact that whatever data you write to the table will actually be written.

I semi-regularly fix a serious data loss bug that has been fixed with an alter table query. Maybe converting VARCHAR to TEXT or INT to BIGINT... of course it doesn't really "fix" your problem, because the data has already been lost/truncated.

What's a real world situation where completely the wrong type could be written to a column? Especially in modern software with good type safety checks/etc to ensure you don't have malicious data inserted into your database? If I ever did have that happen... at least the data hasn't been lost. You can run a simple script to clean up the "horrific" data.

If you used the top row more often, you wouldn't need to look down...

I'm doing it, though I haven't written anything up. Happy to share my opinion though, with a bit more experience than you have.

The databases I'm working with are pretty small - ballpark 4MB of data per "tenant". So, I guess, a single large database sever with half a terabyte of RAM could keep well over a hundred thousand tenants in memory at the same time (I don't have anywhere near that many tenants, so I haven't tested that... and honestly if I did have that many I'd probably split them up between different servers).

Without getting stuck into the into too much detail - "tenant" isn't really a good fit for how we split them up. Our business is largely based on events that happen at a specific date, with maybe a few months of activity before that date. We have an sqlite database for each event (so ~4MB per event). Once the event passes, it's essentially archived and will almost never be accessed. But it won't actually never be accessed so we can't delete it.

I haven't run into any performance issues so far, just with regular sqlite databases on the filesystem. I expect the kernel is doing it's thing and making sure "hot" databases are RAM as with any other frequently accessed file on the disk.

My understanding (it's a theoretical problem I haven't actually encountered...) is SQLite only really struggles when you have a bunch of simultaneous writes. Our business model doesn't have that. The most actively written table is the one where we record credit card payments... and unfortunately we don't make tens of thousands of sales per second.

If we did have that "problem" I'm sure we could allocate some of our billions of dollars per day in profits to finding a way to make it work... my gut instinct would be to continue to use SQLite with some kind of cache in front of it. All writes would go to something faster than SQLite, then be copied to SQLite later. Reads would check the write cache first, and SQLite if the cache misses.

My experience working with a single large database is you end up with a lot of stale data that you is almost never needed. When a table has a hundred million rows, with indexes on multiple columns, even the simplest operating like adding a new row can get slow. My approach with SQLite eliminates that - I'll often have just hundreds of rows in a table and access is blazingly fast. When I need to access another database that hasn't been touched in a long time (years possibly), having to wait, what, an entire millisecond, for the SSD to load that database off the filesystem into memory isn't a big deal. No user is going to notice or complain.

Obviously that's more challenging with some data sets and if you're constantly accessing old data, those milliseconds will add up to significant iowait and things will fall over. I definitely don't use SQLite for all of my databases... but in general if you're doing enough writes for SQLite's simultaneous write performance issue to be a problem... then chances are your data set is going to get very large, very quickly, and you're going to have performance headaches no matter what database you're using.

Finding some way to divide your database is an obvious performance win... and SQLite makes that really easy.

I feel like there must be better options than resistive heating to melt the snow.

For example instead of a separate visor for each light, use a single visor that covers all three lights. And maybe angle the whole thing forwards slightly so that there isn't even a vertical surface for snow to rest on - gravity would simply cause it to fall off.

I'm pretty sure it's "we will figure that out later".

Or... drop an anchor, pull the floating barge against the tide towards the anchor when the sun/wind are optimal. Let the tide pull the barge away from the anchor (with a generator on the winch cable) when you want power while the sun/wind aren't providing power.

Tides have massive potential for power generation. The best part is how predictable they are.

Your idea of weights being raised and lowered makes more sense for land based energy storage (and it is being trialed right now, with promising results).

Or, you could just put them on the roofs of existing buildings. I mean, that's where you need the power right?

All you need then is a grid so you can off load excess power (you're going to have a lot of excess power, if you cover even one in ten roofs in a city) to some kind of storage method and draw back from that when the sun isn't shining.

I would think the environmental difference between a ceramic tile or metal roof and a solar panel roof is pretty minimal.