I feel like this problem is better in the UK than in North America.
For starters, there is higher market penetration for better headlight technology, particularly ADB (adaptive driving beam). North American road safety regulations have made it very difficult to get this technology into cars, whereas in Europe it is reasonably widespread. Even rental cars I have had in the UK have this technology- most recently a Mazda3 which had a very good implementation of it, I could drive through the countryside with high-beams on constantly, and you could see the car quickly dim the beam facing towards oncoming traffic if any came around a bend. These are not high-end cars; I have rented cars with a manual transmission and cloth seats yet better headlights than the fanciest S-class in North America.
There is also less variation in vehicle size, and better emphasis on road safety testing. In Canada I often encounter lifted pickup trucks, which changes the alignment of factory lighting, not to mention the lights on these are often aftermarket anyway and usually installed without any thought for alignment. British pickup trucks are rarer, smaller, and would fail their yearly MOT for having improper headlamp aim.
The problem with headlight brightness has mostly stemmed from cars having brighter headlights. I love technology, but if I had to choose between reducing light output, vs switching to harder-to repair, more expensive, less reliable computer-powered headlights, I'd prefer the former.
When I drive cars with old headlights, they are clearly inferior to the point of feeling nearly dangerous in some situations. I would also not call modern lights less reliable, although I am sure it is more expensive to repair modern lighting technology.
In a North American city where there is overhead lighting and the streets are a mile wide, sure, I could probably turn the lights off even and be totally fine.
In the middle of the British countryside on a single-track road that has hedges on either side, not enough space for cars in the oncoming direction to pass me, a 60mph speed limit, during a rainstorm? I want the nice lights.
There are all manner of health conditions that can occur that have little to do with your own healthy living, and don't incapacitate you or make life not worth living, but will cripple you financially.
You might end up with Crohn's or all manner of autoimmune conditions where patented biologics easily costs north of $100k US a year just in medication, but your quality of life if you find a medication that works is not particularly degraded from the average person.
CrossFit will not prevent you from getting into that situation, and I think it would be a vast overreaction to commit suicide in response to such a diagnosis.
When we moved to Canada from the UK in 2010 there was no real way to access BBC content in a timely manner. My dad learned how to use a VPN and Handbrake to rip BBC iPlayer content and encode it for use on an Apple TV.
You had to do this if you wanted to access the content. The market did not provide any alternative.
Nowadays BBC have a BritBox subscription service. As someone in this middle space, my dad promptly bought a subscription and probably has never fired up Handbrake since.
I don't see what advantage any company gets from choosing to build products that enable personal data ownership. I say this as someone working on a venture with these sorts of design aims, it feels like pushing a boulder uphill often.
The business model of cloud service providers makes a lot of sense- we have a system which stores and operates on your data, you pay some rental fee for us to store it and operate on it, easy peasy. The cost is related to both the utility of the operations the operator performs (to both the operator and the user) and the amount of data the user stores.
Fundamentally this is how everything from Dropbox to Facebook is governed- Dropbox does not devise much utility per GB and users store a lot, so you rent per GB, but at Facebook, they don't store lots of your stuff, and on the data side maybe you don't get much value from it as it's a cesspit, but the data is valuable to Facebook to sell ads, etc, so they can provide the service for free.
Importantly, you don't need to improve the product to continue extracting this rent, because the product you are selling is not Dropbox v4, Facebook v2.3, rather you are selling ongoing access to the rental.
As soon as you introduce even simply a federated system where a few corporate operators are involved, it becomes very hard to justify extracting rent there as the network designer, as the operators are taking on the cost of actually storing the data. You have to really be iterating on the core product to use a SaaS business model here. Some things simply don't need a v4, does Dropbox really need that much iteration?
Meanwhile as the system designer, life has become a lot more complex for you. Suddenly you cannot push unilateral sweeping changes to APIs, you need to version things in a way that is compatible between, say, one university updating their system but not the other. Since your users are a few large operators rather than millions of individuals, you lose the network effect advantage of being able to screw over a few users for the "greater good", since if you irritate one corporate client, you lose a lot of your install base. Why would you voluntarily choose this harder path as a company?
Things get even worse as you increase the level of decentralization. The reality is users expect the polished experience that the rental companies can give you; they want their data always accessible so that their friend can see the pic they shared without needing to keep their own computers running, they want the "like counter" to go up without their personal node subscribing to messages from other nodes, etc. The only users that will accept a worse experience are people who have are motivated by their philosophy re: personal data ownership, and this crowd will want a FOSS solution, so you can say goodbye to charging them for Dropbox v4, they are simply not interested if you're not giving them the source code for free. (I suspect this is where the author sits, but fundamentally I don't think it will get mass appeal, most people simply do not care about data ownership above something that "just works".)
So now you are dealing with problems like dynamic generation of redundant data and fault- and Byzantine-tolerant consensus algorithms so that your system can maintain function even when the user turns their computer off, and you have to deal with wrapped-key cryptography so that the redundant data can be split across all these user nodes without you worrying that an unauthorized user can read it, and then you have issues like how do you deal with nodes that are too slow to process updates (perhaps some user data needs to be stored in this conflict-free replicated datatype you devise), and eventually you go through all of this to... create a system that is less monetizable than the rental model, because you can't extract that rent for ongoing data storage, and we know users are not interested in actually paying for software.
I don't think Framework will be able to compete on efficiency with their design philosophy.
The NVMe disk is swappable, which means it has its own controller which manages power management itself. I did my research to pick an efficient SSD and ended up with a Lexar NM790. It tops Tom's efficiency charts and comes in third place for lowest idle power consumption [0]. This is still ~0.8W at idle. On a 60Wh battery an idling drive alone will kill the battery in 3 days.
Now technically there is the APST (Autonomous Power State Transition) feature in the NVMe specification. Is there some lower APST power state that can get the power draw down? Potentially, but that is a feature well beyond the purview of any SSD reviews I have seen, so I don't know- does this drive have reliable and well-implemented APST state support? How does this interact with the platform-specific sleep state implementation, which presumably wakes the disk sometimes to do some Modern Standby features- how often is it spending time in that 0.8W state versus lower? This can vary between board rev or BIOS version certainly. Beyond the actual drive configuration and ACPI interaction, there is also kernel interaction. Do certain drives behave poorly with Linux? Etc etc.
On the RAM side of things, they are using DDR5 and not LPDDR5. There is a lower voltage on LPPDR5 which is a constant inefficiency, but also LPDDR5 has dynamic voltage scaling and dynamic frequency scaling. There is also technically some voltage drop across the SODIMM connector which you don't need to contend with when you solder RAM, which would be a constant source of loss, but I am not sure how significant that is.
Beyond this you have different behaviour for every model of RAM. This post on the Framework forum shows the user could get 7.82 days of suspend time with the HMCG66MEBSA092N DDR5-4800MHz 16GB kit whereas only 2.25 days with the CT2K48G56C46S5 DDR5-5600MHz 96GB kit [1]. Consider that there are effectively infinite combinations of memory people can run, and even inside a model series, vendors can swap their chip providers, etc. Which kits give the best battery endurance? I can't tell you.
Now someone could certainly embark on a long adventure to test different drives, RAM kits, and measure their performance, recommend tunables for the Linux kernel you want to set for each particular set of hardware, etc. But this is effectively what Apple is doing for you with the MacBook. They are choosing their memory supplier, their flash supplier, and integrating as much as possible into their SoC with presumably an entire team focused on extracting the most efficient behaviour out of both.
Consider this same thing extends to display behaviour (beyond VRR support, which I believe Framework has now, you also have local dimming behaviour to tune on the MBP), wireless behaviour, all sorts of embedded controllers that Apple can wrap inside the SoC that I probably wouldn't think of... I don't see how a modular system like Framework can achieve anything close to the idle efficiency of a MacBook.
The case is part of the utilitarianism. I need to attach my phone to a bike mount. I use a Peak Design case that has a locking attachment point in the centre to securely fasten the phone onto the handlebars.
I would gladly ditch the case if Apple had a strong mounting system integrated into the phone (MagSafe has nowhere near the resistance to shear forces sufficient to hold a phone over bumps on a bike.)
I suppose I am looking for the phone equivalent of a camera thumbscrew mount. If Apple iterated on MagSafe to include an actual mechanical fixture as part of the attachment, I would buy that phone right away so I can avoid using these crappy pieces of rubber/plastic that degrade so much more quickly in appearance than the phone frame rails.
We could potentially see one-time-purchase model checkpoints, where users pay to get a particular version for offline use, and future development is gated behind paying again- but certainly the issue of “some level of AI is good enough for most users” might hurt the infinite growth dreams of VCs
In the UK it has become very common to need to scan a QR code on your table to order at a restaurant, which takes you to a website.
Most certainly you can still order at the bar the old fashioned way, but since COVID, physical menus have been removed, so how is your group meant to decide what it wants to order before one of you goes up on its behalf? (You cannot all go up if you want to hold the table.)
I don't even particularly mind the experience of using the website; the interface enables the display of all ingredients & allows you to specify allergens they need to avoid. If the kitchen runs out of an item, they can mark it as unavailable in the webpage. Finally, fighting to order at a busy bar was never a fun experience to begin with (it is the norm in non-fine-dining experiences in the UK to not have your order taken at your table.) But, this does require you allow arbitrary internet access on your device, which complexifies the blocking situation.
Yes it's exactly the one-off situations like that, which aren't super often but occur enough to greatly inconvenience someone without a pocket browser.
Unless you need the GPIO pins it is likely a better choice to go with one of the many x86 mini PCs on Amazon, although you need to ensure it is not totally no-name.
I got a GMKtec G5 which is about ~3"x3"x2", has an Intel N97 CPU, 12GB of RAM, and a 512GB SSD (upgraded to a 2TB NVMe disk). No need to buy an additional power adapter (included, it's Type-C), HDMI adapters, or case/fan, either. I think it was about £110 with next-day shipping from Amazon.
It has remarkable performance; I tried GNOME on NixOS and it felt instantly responsive for all general purpose desktop use (web browsing, vscodium with my linting extensions, etc). The only area of my everyday workflow in which it clearly fell behind my M1 Max MacBook Pro was in Rust compilation which is obviously expected - I was just shocked how close it was for everything outside of that. This is in huge contrast to Raspberry Pis which suck to use graphically, even with the Pi 5.
It has happily been sitting on my desk running Forgejo, Mastodon, Vaultwarden, and acting as a personal storage server with that 2TB drive for the last ~6 months and I never even hear the fan. Sits at 0.1 load average, despite Mastodon with this many relays previously eating up the contabo VPS' CPU I was using quite handily.
If you need GPIO support on a mini-PC you can just use a cheap FT232H breakout [1] with either PyFTDI [2], which supports pretty much all the protocols you need (UART/GPIO/SPI/I2C), or alternatively use CircuitPython with Blinka [3] which gives you access to the CircuitPython drivers etc.
I do not think determinism of behaviour is the only thing that matters for evaluating the value of an abstraction - exposure to the output is also a consideration.
The behaviour of the = operator in Python is certainly deterministic and well-documented, but depending on context it can result in either a copy (2x memory consumption) or a pointer (+64bit memory consumption). Values that were previously pointers can also suddenly become copies following later permutation. Do you think this through every time you use =? The consequences of this can be significant (e.g. operating on a large file in memory); I have seen SWEs make errors in FastAPI multipart upload pipelines that have increased memory consumption by 2x, 3x, in this manner.
Meanwhile I can ask an LLM to generate me Rust code, and it is clearly obvious what impact the generated code has on memory consumption. If it is a reassignment (b = a) it will be a move, and future attempts to access the value of a would refuse to compile and be highlighted immediately in an IDE linter. If the LLM does b = &a, it is clearly borrowing, which has the size of a pointer (+64bits). If the LLM did b = a.clone(), I would clearly be able to see that we are duplicating this data structure in memory (2x consumption).
The LLM code certainly is non-deterministic; it will be different depending on the questions I asked (unlike a compiler). However, in this particular example, the chosen output format/language (Rust) directly exposes me to the underlying behaviour in a way that is both lower-level than Python (what I might choose to write quick code myself) yet also much, much more interpretable as a human than, say, a binary that GCC produces. I think this has significant value.
For starters, there is higher market penetration for better headlight technology, particularly ADB (adaptive driving beam). North American road safety regulations have made it very difficult to get this technology into cars, whereas in Europe it is reasonably widespread. Even rental cars I have had in the UK have this technology- most recently a Mazda3 which had a very good implementation of it, I could drive through the countryside with high-beams on constantly, and you could see the car quickly dim the beam facing towards oncoming traffic if any came around a bend. These are not high-end cars; I have rented cars with a manual transmission and cloth seats yet better headlights than the fanciest S-class in North America.
There is also less variation in vehicle size, and better emphasis on road safety testing. In Canada I often encounter lifted pickup trucks, which changes the alignment of factory lighting, not to mention the lights on these are often aftermarket anyway and usually installed without any thought for alignment. British pickup trucks are rarer, smaller, and would fail their yearly MOT for having improper headlamp aim.
reply