HN user
I wouldn't go as far as telling something is badly written just because it's written to work on one platform. It can be an exceptional application even when it only works using a single platforms' intrinsics. Similarly a badly written application may work on many platforms
Specifically for Video encoding I'd look into benchmarks about what certain ARM architectures can do. Not all encoders can correctly utilize them and they may end up very slow.
Annual purchases don't have setup fees as far as a I know, but it's probably just a way to charge more if you're only using it for a short while
I'd say the part
versus the AWS shop where the Dynamo guy knew the innards of the database by chapter and verse)
Definitely has a big impact on it. The angle at which people approach these databases is completely different from my experience. MongoDB is advertised with words like "developer friendly" and "just works", so people tend to just start it up and not read too much into it.
On the other hand DynamoDB was described to us as "monkey's paw", "Carefully read before use", "know what you're doing". And so we combed through first all the pitfall blogs, then AWS documentation, and then carefully tried out all the features we wanted to use and tested the scenarios separately.
I wonder how that would fare in our climate in finland, where the ground freezes and thaws all the time, breaking just about everything we lay in it, including roads, signs, pipes, foundations...
This is anecdotal of course, but for me cooling with AC is easily over half of energy bills I get.
Cloud pricing for bandwidth is really limiting for a lot of applications. For comparison you can get a 1gbit/s line with your server on OVH EU for about $100/mo, which you could utilize for a theoretical ~321TiB/mo total transferred
Wikipedia says it is
A local Internet registry (LIR) is an organization that has been allocated a block of IP addresses by a RIR, and that assigns most parts of this block to its own customers
RIR being Regional Internet Registry
Doesen't /64 mean that you can't create additional subnets within your ISP given range? I thought /56 was the smallest allocation an ISP could make for a residential allocation.
I think it's great that the smallest subnet size is designed to be as large as to never run out of addresses in any conceivable application, no more wasting precious time manually assigning addresses and thinking about subnet economics
I've been browsing their site for a few minutes now and I'm still lost on what Fleet actually is.
It says it's a new IDE, built from scratch, sure, but isn't IntelliJ already the gold standard for many languages? What problems does creating an entirely new IDE solve?
A thing to consider is the average means there are tons of older cars in the mix, but some new ones slowly creeping in. There are lots of cars from the 90s or even 80s driving around where I'm from. Weather can be quite unforgiving for cars here, temperature ranging from -25C(-13F) to +30C(86F) year round. Lots of salt and some types of pavement seem to be exceptionally bad for timing gears[0]. Owning a car is likely the most expensive thing a normal person can do in Finland.
We already have a lot of excess capacity at night. Slowly charging EVs could even be a net-boon for required peaker plants if people could cover their own needs for the 15% of the day
Covering only 95% cases means you save a lot of money, part of which can be used for those rare events. Does taking a taxi to see a dying relative a couple hundred miles away cost a lot? Sure, but owning a ton of unused capacity for years costs a lot more.
Going anywhere where EV couldn't reach would most often require some sort of reservations; hotels, skiing resorts, museums, sight seeing etc all require some sort of planning if you don't want to absolutely burn money buying things ad-hoc, which would go counter the point of saving money with an ICE anyway.
A month or two in advance is just fine, most people can do as much. They do know how many days of vacation they get though, and it's unlikely to change, so any plan you have you keep.
you can't dangle a cable from your house to your car (which may not be outside of your house).
That must vary between countries, because I've seen tons of outlets on the outside walls of homes in Finland. They need a weatherproof extension cord, but it comes in handy for a lot of tools. Though most homes have at least a driveway, cars are generally shorter than homes, so they fit close by.
The cost of free parking and where to park should really be reconsidered in cities though, as with your image, those exist here as well and are really bad places to drive in. IIRC in Japan they require people to prove a car has it's own dedicated parking space before they're allowed to get a car
Some parking spaces may be designed for bursting loads, and the wires actually do heat up if used continuously. They may still need upgrades for EVs, but overall should be only a modest cost.
And people's plans are already made for whatever days they get, so unless there's a sudden influx of vacations, more trips just won't happen. That is of course expecting people can also afford extra trips, the locations themselves often being quite expensive.
Considering we've switched from overhanging wires to putting our electric infrastructure underground (very, very expensive), I think we can pull off upgrades in parking lots too.
The average age of a car is ~12[0] years in Finland. Out of the 7 people I often interact with that have cars, 7 have had those, and a lot of other parts fail
[0] https://moottori.fi/liikenne/jutut/suomen-henkiloauton-keski...
Anyone with mechanical knowledge, tools, and patience can
Just like everyone with a PC and an internet connection can become a software developer; there are a few steps in between why it doesen't "just" happen
Depends on your aparment blocks of course. Over here we have parking spaces for residdents living in apartments, which have electrical outlets. The space is already there, just needs an electrical upgrade
People in hot countries still tend not to drive several hundred mile trips trough the desert, they work reasonably close to where they live. For whatever around-the-globe fun trip you can of course rent whatever you want
Unless employers suddenly start handing out extra months worth vacations, an extra family trip sounds unlikely, let alone 10.
With the generally available rewriteable blu-ray capacity, doing this would be quite burdensome to archive even some couple terabytes. Would recommend multiple online harddrives, preferably far apart from each other and some append-only mode to prevent accidental deletion. Or a cheap online-backup service, or both.
There is no single good answer for this. Data generally needs to be constantly taken care of to survive. This will necessarily require some amount of trust since you can't be in control when you're dead, and after the timer unlocking, just about anyone with physical access to the key can open containers with it
S3 max filesize is 5TB, so with that you'd have to have atleast 8 archive files. You can use byteranges to fetch only a single file out of it if you have the means to determine that range.
You can, though this will incur some costs related to temporarily storing your data in S3, as it either won't be immediately transferred when using lifecycle policies, or will incur extra charges if you force a type change based on filesizes and filecount.
Note that there is also a minimum filesize of 128KB per object in Glacier as well as 32KB extra metadata, and everything smaller will also be counted as the minimum size. Some mitigate this by bundling files in larger chunks, at the cost of retrievability and now having to keep an map of file-bundle associations.
Could be, but it could also be a fluke. Perhaps everything after the first file-index file is corrupted, and you only restored things from the first one, or perhaps maybe the entire diff-index can be so large that it's not actually recoverable once you grow it to the size you want.
There are a myriad of easy-to-miss failure scenarios that don't appear in small-scale tests. Only way to ensure you can restore your backups, is to restore your backups
Backups should always be tested atleast once to ensure that they do in fact work. Nothing worse than losing data, and discovering that you've been paying a service for naught all those years. This could get prohibitively expensive if you can't replicate your setup in the cloud to test backups within AWS network.
Or you could just blindly trust that it'll work. Kind of like schrödingers backup
Disasters often bring financial difficulty, in which cost of repair is very much a problem. It's hard to justify for any individual when much cheaper and easier to use and understand services are available. It's great if your enterprise is looking for a compliance checkbox to tick, Glacier can save a lot of time in that case.