

Oh joy, another rebrand. Maybe they’ll redo the logo again too. Send like a reasonable use of time and resources.
Canadian software engineer living in Europe.


Oh joy, another rebrand. Maybe they’ll redo the logo again too. Send like a reasonable use of time and resources.


Your math is waaaaay off. Let me help you.:
Let’s assume that you commute a rather conservative distance of just 25mi to work. That’s 50mi/day, 5 days/wk, plus let’s say half that over the weekend. Assuming an (again, generous) fuel efficiency for your truck at 25mpg, given a ballpark 300mi/week, that’s 12 gallons of fuel/week. The current average price of gas in the US is a remarkably low $3.071, and that adds up to $36.85/week.
Now consider the costs of maintenance. If you’ve really had zero problems in the last 20 years on a pickup truck (honestly this is far from average), you likely did an oil change every 3 months at the very least. These days it’ll run you about $100.
In terms of insurance, I asked this site for the average cost of insuring a Toyota pickup truck for one year: $1937. Let’s be grossly optimistic and pretend that those rates will never go up.
Initial cost: (Provided) = 11000.00
Fuel costs: (50 × 6 ÷ 25 × 3.071 × 52 × 20) = 38326.08
Oil changes: ($100 × 4 × 20) = 8000.00
Insurance: (1937 × 20) = 38740.00
Parking: = ?
------------------------------------------------------
Total 96066.08
Excluding the cost of parking, the purchase of your miracle never-needs-repair truck if purchased today would be roughly $100,000. Note also how very conservative these values are. It’s entirely possible that your real costs are well above what I’ve stated here.
The total cost of the rental was $1000 plus fuel costs, so using our above figures, that’s a grand total of $1042.99 assuming you drove it roughly 50mi/day for all 7 days of the week. That’s assuming that you don’t opt for the much lower rates that appear to be available to you in the area of $250 - $350/week.
So, if you didn’t own a car and instead only rented one when you needed to “move a couch”, you would save just over $95,000. In other words, your insistence that you absolutely must own your own vehicle has cost you the equivalent of a downpayment on a house.


Car rentals are exceptionally cheap compared to paying to own and drive a car capable of hauling a couch for that one time 4 years ago when you needed that.


As a big car-hater myself, I can agree with most of what you’re saying here (the “but it snows” argument is baseless though, see Denmark).
I think that if you’ve chosen to live in sparsely populated areas, then being car-dependent is your choice and you should be able to have that… but you don’t get to drive your car into the city.
Cars ruin cities. They’re loud, dangerous, dirty, and they kill millions. If you’re happy to live like that, then that’s on you, but you (I’m using the “motorist demographic” here rather then the personal “you”) can’t insist on having wide, multi-lane, high speed roads and plenty of free parking where most of the world’s population actually lives. You park at the periphery and take transit or a bike into town.


If you build for a containerised environment, standing up your service in Kubernetes with HPA gives you all the scalability (and potentially cost) benefits of serverless without all the drawbacks.
“Oh hi! Here’s some code. I didn’t write it and don’t understand it, but you should totally run it on your machine.”
Does this mean we can finally ditch all those memory-hungry Electron apps?
I love it, and have some feedback of you’re interested:


Plus the FF extension is really full-featured. I can clip in different formats or even take a screenshot if the webpage makes clipping hard.
I didn’t even know there was a Firefox extension! I might give it a look.


I’m afraid I have no idea what an RCS is, but maybe that’s a network/region specific thing? I’m in the UK using GiffGaff (O₂) and the phone, SMS, and data works exactly as well as everyone else’s… which is to say perfectly in most places and sporadically on the train due to the dead zones on the route.


I’m using a Fairphone 4, which is 4 years old at this point (October 2021) and I’m still quite happy with it, but I owned the Fairphone 1 and 2 as well.
In terms of software atrophy, they do offer support for your device for 5 years, which is better than most, and because of its open nature, it’s generally well supported by alternatives like Lineage or Calyx, but yeah, I’m still on Android 13. While I still get regular security patches and haven’t really had a need for an upgrade, there’s no denying that the FP4 is behind.
Of course, it’s also easily repairable, supports an SD card and replaceable battery, so that’s a tradeoff I’m happy with.


I’d rather see a stable OS and ecosystem for good, Free apps that we can flash onto existing devices. I’m quite happy with my Fairphone (repairable! modular! ethical!) and we know that building and marketing a device is painfully expensive.
Let’s make Debian or Arch just work on most phones instead of trying to compete in a saturated market.
What exactly is an external drive case? Are you just talking about a USB enclosure for a single drive or something that can somehow hold multiple drives and interface over something more stable than USB?


Joplin will do this for you. It comes ready to sync with all sorts of cloud options, as well as “local folder” which works well with Syncthing. It’s offline-first, cross-platform, and FOSS.


I hadn’t considered Syncthing. One could for example bake the syncthing protocol into an SSB-based app such that whenever a paired device comes online it automatically syncs data over so to the user things are seemingly centralised. The only risk I can see there is a case where Device A is turned off before Device B is turned on, so the sync wouldn’t carry over. That’s a small price to pay though I think, and something people could learn to work around.
It’s funny, I do exactly what you describe, but with Joplin, though it never occurred to me to reach for Syncthing in this case. Thanks!


No, I was wanting to go the step further and target “offline first” to avoid the need for too many “always on” services. From a philosophical perspective, I think our internet should be able to function without the resources required to run something 24hrs/day.
You can absolutely build a LinkedIn clone on top of something like ActivityPub for example, but I’m not sure how one might do that from an “offline first” perspective though.
Edit: I just remembered my primary objection to this argument: most people aren’t nerds. You can’t have a properly distributed web if federating requires access to (a) an always on server, and (b) the skills to maintain it yourself. I’d argue that this is precisely why the fediverse is so dominated by Free software nerds like me. No, it has to be easy: install an app on my phone, start writing. Let the app figure out how to connect everything, and if I get on a boat/plane/train or my phone runs out of battery, connectivity should Just Work™. This is what I love about SSB: whatever we build on top of it, the protocol was already designed on this assumption.


I had exactly this thought just over a month ago. After mulling it over for a few days, I decided that the only reasonable way to build it would be on top of Scuttlebutt. Alice shares her CV, makes it available via a pub, Bob shares a job description at the same pub, and the two can connect through there, etc.
The advantage of SSB is the absence of the need for an always-on, big data cloud service. The project instead is managed by a swarm of phones all connecting intermittently. It’s very solarpunk.
The big problem for me was the multiple device question. If Alice wants to interact with “FreeLinkedIn” both on her phone and her laptop sporadically over many days, you still need a cloud device to hold state, negating all the benefits granted from SSB. I couldn’t figure a way around this, and then got distracted.
That’s exactly the reasoning Google has followed with its development and promotion of webp. Unfortunately, whether the website cares or not, CO₂ emissions are markedly higher due to increased client energy consumption, and that does directly affect you, so it’s worth considering the implications of using webp in a popular site.
Webp is pretty great actually. Supporting a 32bit alpha channel means I’ve actually managed to reduce file sizes of what were formerly PNGs by something like 80%, which drastically improved performance (and the size of my project). I don’t get where the complaint of image quality came from either, as it seems to perform better than JPEG at the same file size.
The worst part is that you missed the real problem with the format: the CPU overhead (and therefore the energy cost) of handling the file. A high-traffic site can dramatically increase the energy required for the images processed by the thousands/millions of clients in a single day, which places a drain on the grid and emits more CO₂ (yes, this is really a thing that people measure now).
Basically Google invented the format to externalise their costs. Now, rather than footing the bill for bigger datacentres and greater bandwidth, they made everyone else pay for decompression.
They’re all on the high seas and they’re all excellent.