US has a huge advantage compared to France. US has the control of its currency and can devalue it. France cannot do it since Euro is not controlled by France.
Looks great, I'm definitely going to have a look at it.
Off-topic: it'd be nice to have a configuration spec to define the look (and maybe even the behaviour) of the different CLI & TUI libraries out there. For things like colours/borders/corners/shadows/scroll- & progressbars etc.
Right now every library does its own thing, which can be quite jarring when using different apps.
To a degree, yes, but I was thinking something in the line of a commonly agreed on file format that defines a default style. To be used by libraries like charm, ratatui, tty, heck maybe even older ones like libnewt etc.
A bit like base16 but with more definitions and better semantics.
I want to like framework, but whenever I've seen one of them in person I was pretty disappointed about the case/chassis. And the touchpad.
For me personally, weight doesn't matter that much, and neither does configurability (I guess by now they have data on the most popular port choices for example).
But size (as small/minimal as possible for a given screen and keyboard size – minimal bezels for both) and strength (no flex, solid hinge) do matter to me.
I understand these two things conflict with themselves, and with the framework's repairability and configurability.
Still, I'd like to see some true innovation there. I'm just afraid they painted themselves into a corner with their current mainboard design, and won't be able to diverge from that to bring us something truly solid yet compact and repairable.
I was hoping to use bcachefs to have one pool with subvolumes for root (encrypted by tpm), and for the home folders (also encrypted but with different keys, for example for systemd-homed use).
Any chance for different encryption keys per subvolume?
I wrote this controversial thought[1] once, but for what it's worth, it applied to me just as much as to anyone else. Projects like these type gems are incredibly fun and satisfying to build. Your vision is clear, you've seen types before, you're proficient enough with Ruby to do clever things. The work seems cut out for you. Go nuts!
Problem is, these kinds of solutions (I also see this in "service objects" world) take Ruby away from you, and offer you a whole new vocabulary. With time I started appreciating libraries that avoid solving a problem that plain Ruby can solve, because Ruby is incredibly clear and concise already. If you leave more opportunities for people to write plain Ruby, you will solve everything with much less library code.
I think that's where the fun of building goes against the end developer experience. Builders love "owning" everything. E.g, "No, don't write `&&`, I have a special way for you to compose types!"
These are general thoughts, but I'm happy to get concrete with specific examples too.
> I'd also really like to see affirmations that Matter is usable sans any big network, sans Google Apple and whomever else. That it really is something we can run ourselves.
I'm using Matter (over Thread, mostly) with Home Assistant – in addition to using it with Apple HomeKit, but I could have done it exclusively HA. My devices get an IPv6 ULA from the border router, HA can directly talk to them without any internet or cloud involved. Does this qualify?
It's true that certain non-standardized features are only available through "extensions" ie. the device vendor app. But both Thread and Matter get new revisions, and the devices get firmware updates in a standard way (again, installable via Home Assistant) to take advantage of new features and stability updates. All of this has gotten better with time.
But the best thing about Matter is that I'm not locked into a specific ecosystem or dependent on an app from the device vendor. So, in my view it has been a slow start but with steady improvement. And the right direction IMHO.
This is why Debian users should use apt-listchanges to display the latest NEWS.Debian items on upgrade.
I wouldn't expect to see all the important news of the tens of thousands of packages I don't have installed in the release notes.
I was hit by this using unstable (before they made a NEWS item), but when upgrading my stable machines to trixie I got a proper warning/reminder of this specific thing.
You’re not wrong in general terms, but tzdata is fairly well essential, a default component, and a dependency for unpteen things in the ecosystem. Of course a line must be drawn somewhere, but this really is a “major” caveat.
While I was originally interested in the promise of bitcoin as a means of exchanging money bypassing banks, these days I'm wondering if complete secrecy is still a good idea.
Are taxes – any taxation at all – a good idea? I would say yes – funding common infrastructure and services as charities or private companies seems doomed to fail. Making all financial transactions secret would make tax evasion rampant.
What about money coming from criminal enterprises, ie. money laundering. What about extreme concentration of money, having an outsized and untraceable influence on our political system and increasing regulatory capture to the extreme.
I'm not against disruption of our financial system in principle, but it seems we'll first need to also come up with good answers on how we organize society. A society of working poor, with a small but extremely wealthy elite doesn't seem like a good deal – even for the extremely wealthy.
You don't need to implement a sales or income tax in order to subsidize the government's operations. One proposal by "single tax" based on property tax, proposed by a certain Henry George has interesting merits. One such merit is that it is pretty hard to hide from a property tax.
I think that in this century we've become accustomed to the existing credit card payment systems that have access to all of our payment data and are allowed to do with it what they wish (and by extension, the government also can subpoena our payment data in investigations). But if you look back in history this is a pretty new idea. Giving the government access to every single payment you make is pretty dangerous if you have a change of regime into something more authoritarian like in the case of China.
I think that if cryptocurrency can provide about the same level of fungibility and privacy as ordinary cash, that would be fine. You can track marked bills with some level of effort (kind of analogous to an EAE attack in the cryptocurrency world) but the general principle is that not every transaction is automatically logged in some easily inspectable database and sold to the highest bidder.
I myself am unsure where I stand on RBS. I wouldn't mind more use of it in my gem dependencies, but would probably not like it if it was enforced everywhere.
For now I'll stick with improving my test/spec-writing skills, and maybe some runtime type checking like https://literal.fun/
I think RBS is a decent tool, I don't mind it as long as it never becomes a requirement for anything. I hate the trend of statically typed dynamic languages because it's all of the pain without the main benefit (native speed).
