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.
> 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.
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.
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.
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.
20% of the Sahara would be 331 terawatts of solar panels.
To put it in perspective that's an order of magnitude more than the entire global power consumption right now.
I mean sure, I guess one day we'll probably consume that much power. But it won't all come from one place. It will be diversified from solar panels spread all over the world as well as and countless other forms of energy generation.
Covering 20% of the Sahara in solar is a ridiculous scenario. And the impact would be, what, a slight weather variation in a few other places around the world? OK. Sounds pretty good actually.
> the program is in control of the main event loop, user input is handled as part of program flow
Is that supposed to be a good thing? I don't want to write an event loop - I'll probably screw it up and introduce bugs.
> the program state is both minimal [...]
Um... The comparison of normal web programming and your proposed alternative shows an order of magnitude more code for the same result. And it's not even really the same result, I can't select text and right click to copy for example. What about complex things like varying the UX depending on the size of the screen and input method. Or accessibility features for someone who's blind or can't move their hands... those aren't optional.
> and cleanly separated.
Huh? You've got a function called "loop()" that contains all of the code. Where is the separation?
If Meta does that, they will be creating their own walled garden next to the Apple one. Meta won't allow pirated software and malware to run rampant on their own store.
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.