300 karma · joined April 17, 2023
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.
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.
OP: this is important. There are a million tools to generate PDF files, most of them don't produce nice looking PDFs.
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.
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.
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 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.
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.
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.
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).
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.
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.
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?
The new comglomerate of "baby bells" isn't even the biggest Telco provider in the USA, let alone the biggest company in the USA... let alone the biggest in the world.
I don't think Apple can have a requirement to use their proprietary tools. That would be anti-competitive. If they want to make money off the tools... they should just charge a fee to buy the tools.
I would hope that the technical protections protecting user data apply to all apps and not just apps that come from Apple's store. If an app from the store wants to access your contacts or your location, the user has to approve it. Should be exactly the same with side loaded apps.
Vender lock in such as a core operating system feature that can only be accessed with Apple approved apps would be blatant anti-competitive behaviour.
> Google have something like this when you sideload (or allow sideloading option, don't remember exactly when you get these warnings) and EU did not consider it "anti-competitive" (at least yet).
The EU and the USA have both found those warnings to be anti-competitive. In the EU's case, they have the same deadline as Apple to fix it. In the USA, Google was recently fined several hundred million dollars (and will also be required to change the alerts).
I'm sure there will be some warnings, but it they will have to be reasonable - such as "[Name] is an app you downloaded from the internet. Are you sure you want to open it? Safari downloaded this app today from [Website URL]" - that's the message you get right now side-loading an app on a Mac, I think it would be hard for Apple to justify anything more "scary" than that.
MD5 is fine for the first task, and totally unacceptable for the second.
Using real guns is totally normal, because they fire real explosives (so you get a muzzle flash) which can and occasionally do kill people - the only difference between a proper gun and the ones they use in movies is you need to be a lot closer to the movie weapon to be killed by it.
What's not normal is a lack of adequate safety checks around handling of the weapons and there were severe complaints about inadequate breaks for crew and even unconfirmed reports of other people injured by prop guns prior to that day on the same film set. It can be a really difficult issue to deal with - you have literally thousands of people to coordinate.
Exact details of what happened in the Alec Baldwin case are unclear, manslaughter chargers are still winding through the courts, and they include a charge of tampering with evidence which means we may never find out what really happened.
What I can say, working in the acting industry, is I have often been tired (back to back 22 hour shifts where you're forced to eat and drink while working will do that to you) and I've made mistakes while operating in those conditions and seen other people make mistakes that resulted in serious injuries. Managing breaks is a real problem in the industry and technical difficulties are one of the most common causes of delays.
It's not just compute power, I was generalising with that statement. The real world speed hit can be as bad as read speeds an order of magnitude slower than if you disable compression.
You really only want to compress data where it makes sense to compress it.
And a lot of data is already compressed (images, etc) so might increase your compute cost without any storage savings.
Filesystems are often the wrong level in the stack to do compression. You want individual control over what data is compressed.
The better organised venues write those changes down with a pen, so it's at least up to date, but modern venues have several entrances to get people through the doors faster, so most people won't have the up to date paper backup.
Our system uses a cross platform app on ordinary smart phones to scan tickets. So if a device goes down, you just need to get your hands on another phone.
There's a limited feature set version of the QR code scanner (scan code, screen flashes red or green) that just runs in a web browser on any device with a half decent camera. All you need is the secret URL for the tonights event — which we also expose via a QR code.
Dunno. I wasn't so much answering the "who wouldn't use Postgres" question, I was more answering "who could possibly care about 1 second of downtime" question.
I seriously considered Postgres, and I will reconsider that choice regularly.
There are things we have in SQLite right now that would absolutely be better in Postgres, but for the moment we've decided those benefits don't justify the overhead of two completely different database system.
> I really am not conviced that 1 second downtime to restart PostgreSQL out of 24/7/365 would make more of a dent on your companys profits
Our customers are not the people buying tickets. Our customers are the people selling tickets, and our profit is a percentage of their annual revenue. They're moderately sized companies with hundreds of staff.
Which means a single dissatisfied person, at the wrong level of management, can cost us hundreds of thousands of dollars. Downtime is inevitable and we don't claim to offer 100% uptime... but we try really really hard to be as close to that as possible. That includes encouraging people to print, on dead tree paper, a copy of their ticket sales database five minutes before they open the doors for a performance. But that copy is always out of date, since they sell tickets after opening the doors, so it's not a great backup.
These aren't tech savvy people. You don't hire an IT person to stand at a door scanning a thousand QR codes for 20 minutes three nights a week.