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.

>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.

You don't need bluetooth to do that. By keeping track of your public/private ip (which requires no special permissions), and correlating it to time of day, it's fairly easy to infer whether you're home or not. If there's a network you're regularly connected to during the evening and weekends, it's highly probable that you're "home".

"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.

I guess once you get to a certain point, you need to hire engineers that have strong SQL skills in order to scale.

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.

Isn't this kinda like mounting a fan on your car's roof to charge the battery? You have accelerated your spaceship to 0.995C (or whatever) and now you are encountering space dust at a phenomenal rate. Some of that dust is moving away from you, some of it toward you, some of it is at rest. On average it's all just sitting there unaware that your vessel is about to smack into it. The energy is in the difference between your speed and the particle's. If you try to harness it, you slow down.

(I'm asking genuinely here. My analogy might be wrong because it's too classical!)

I think in principle you should be able to generate thrust greater than drag orthogonal to the particle flow. That's what wings do.

The old Bussard ramjet concept was to capture these high velocity protons (with some kind of magnetic field), cause them to fuse, and use the fusion energy for propulsion.

There are a few engineering difficulties with the idea but it makes for some good SF stories...

The spaceship in Poul Anderson's Tau Zero uses a Bussard ramjet.

Fantastic book. I read it for the first time about a year ago but I still think about it once every week or two. Thought about it as soon as the "spaceship" started to accelerate towards light speed.

Also all Stat Trek Federation ships

Relativity effects will start to bite. The proton's going to stop being interested in your magnetic field[1], and you're approaching the velocity of the exhaust mass of the fusion reaction.

[1] The momentum vector just completely flattens almost any other physical characteristic. I'm not sure there's even enough time for nuclear fusion to take place.

There's two different kinds of energy here - the kinetic energy of a moving thing hitting you in opposition is a problem. No way to capture that as far as I know - it's like running into a wall and asking how it can help you go faster.

But then there's e=mc^2, so if the stuff you're running into is the fuel source for your fusion engine (could be a fission engine, but unlikely you'll run into heavy atoms like Uranium or Plutonium) then you have an unlimited source of energy...

So maybe sort of? Running into things slows you down, but then you capture that mass and release the energy out of it to go faster... because of the nature of e=mc^2 you'll usually get more energy out of something if you convert its mass than what you lose by running into that mass.

I’m imagining a ship with a hole in it and a piece of fuel at the backside where the particles hit. It would slow you down first since you’re tethered to the particles, then the explosion would push you forward.

The issue is that the energy for that explosion comes from the slowing down of your ship, so it doesn’t work.

The energy that comes from a mass-energy conversion greatly exceeds kinetic energy losses.

For the same reason that the power of an atomic bomb does not depend on how fast you smash the sections together - it depends on how much mass is converted to energy in the resulting reaction.

This is a bit like driving into a brick wall, and then asking if you could use the released energy to go faster ...

Imagine you drive into a wall of tnt, break through it, and as you exit it explodes and gives you an extra boost. Yes, you’ve lost some speed at the beginning but you’ve gained much more

The tnt has potential energy. The only reason those protons have energy is because you’re smacking through them with energy you’ve already found.

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.

Obviously writing software with bugs in it shouldn’t be illegal, unless in violation of the SLA.

But knowing this and lying about it, as was done by the Postal Service, Fujitsu management and insurance companies, most definitely should.

You shouldn’t be liable for mistakes, but you should be liable for malcontent

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.

> They're not that hard to extinguish, you can just wait for them to stop burning on their own.

Pity about the apartment building that burns down around them, eh?

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.

I don't find a DB that losslessly stores what I told it to store regardless of types worrying at all.

So in fact AFAIC the misfeature of SQLite is not that it's typeless, IMO, rather it's that it has this notion of NUMERIC affinity that's all but lossless.

E.g. SQLite has a decimal extension that allows you to work with decimal numbers represented as TEXT, and so is appropriate to handle money without rounding issues. However, if you have a column where the declared type is DECIMAL, MONEY, NUMBER, NUMERIC or whatever it will have NUMERIC affinity. Then if you store a textual decimal number to it, it will deduce it looks like a FLOAT and convert, loosing precision.

Your only solution is to use BLOB affinity (declare no type), which is what I do, most of the time.

This is precisely the issue. Databases should not guess at what you want, nor be helpful and make your query work with incorrect types specified.

Schema is rigid; that’s the point. If the input is incorrect, log an error.

It's a bit hard to take your objection very seriously when the following spits out the same SQLite as in PostgreSQL:

    CREATE TABLE tbl (x integer, y real);
    INSERT INTO tbl VALUES ('001', ' 2.5 ');
    SELECT * FROM tbl;

    1|2.5

Numeric affinity was "invented" in SQLite to make it more compatible with PostgreSQL (et al.).

> What's a real world situation where completely the wrong type could be written to a column?

* App with incorrect schema definition is deployed

* App written in TS or Python has type checks disabled

* App written in JS does math, and its fun parsing system decides that 1 + “1” == “11”

I’ve seen all of these.

> You can run a simple script to clean up the "horrific" data.

Depends on scale, and the tables / columns. If there are billions of rows, and the columns with incorrect data aren’t indexed… that’s a bad time.

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