For those that are looking for something more advanced in the Android space a friend of mine built https://limitphone.com/ to handle something like this. It requires a reset, but comes with a lot more options.
Looks very interesting. The price is not good. I mean, we have to do it for 4 fones, that is 120 dollars per year, which is a lot of money, not in it's own, but it ads up with other subscriptions. The trial is too short, i think a months will be better.
This is why I love Lucia. They took the "teach a man to fish" route when they converted to a docs only approach. Now I've got my own auth system and understand a lot more about security.
I find the list hilarious, because Ben Franklin was a notorious player, and his time in France (as American ambassador) was legendary - if documented today, it would make the Wolf of Wallstreet jealous. In modern parlance, ‘coke and hookers’ galore.
He also, by all accounts, was instrumental in getting France to support the US war of independence, without which the war would likely have gone an entirely different way.
Not to say he treated anyone badly - by all accounts, all participants enjoyed themselves immensely.
But don’t take these pronouncements as documentations of fact, but rather playing to an audience. He was also one of the major publishers and propagandists in early America, and his audience was profoundly conservative (often in the puritan sense), rural, and poor. It’s how he made one of his first fortunes [https://en.m.wikipedia.org/wiki/Poor_Richard%27s_Almanack].
He probably did follow some of them, when it suited him, but clearly was never hesitant to let them get in the way of a good time either. Taking it too literally is like taking one of those popular business books too literally.
Considering he didn’t have any embassy bureaucracy beyond a few staff helping him, and that any reply from washington would be many weeks away… it seems extremely unlikely he would have had much free time at all in Paris.
which part? your timelines seem pretty off if you think ‘weeks’ was a remotely possible timeline at the time either.
There was no electronic communication of any sort (electricity was barely understood at the time), and best case transit time was around 6 weeks each way, often 8-12 if possible at all. It was also highly seasonal, and still very dangerous.
So the absolute fastest turn around time was 12 weeks/3 months, and more realistically 4-6 months. With some decent odds that one of the legs of the trip might sink, losing all hands.
It’s why a literal founding father (and one of the most influential ones) was the ambassador. No one else could be trusted.
You seem very confused… “many weeks” was the exact quote. “few” was only brought up after the bizarre reply as part of the explanation in “>>few weeks”.
And yes “many weeks” easily covers the range of 20 to 30 weeks.
I was teaching my dog to bark less, and I worried a bit that it might make him sit silently when I actually want him to bark, like if a stranger was coming through the window.
After a ton of training I realized he will never stop barking, he can realize that what he is doing is not right, but the urge to bark at every noise he hears will always be something we have to work on. We will never get it "right".
I think Ben Franklins strict rules are the same way. Obviously you can't run your entire life with military discipline, but you have to set the ideal fairly high because you are going to fall short over and over.
my dogs, when I have them, dont bark, but have exceptional freedom and are expected to act with discretion, I talk to my animals a lot, and watch them closely, responding to there needs and comunications......a big dogs warning "CHUFF" says everything needed....."big dog here....please observe formalitys, aproach calmly, say hi, be pleaant and confident, and all will be fine", with the understanding that I can order a stand down, for non dog people who are of no threat.
dogs, and animals, offer a real ,genuine , opinion on many aspects of life, a check.......,can I walk away from that expectant look...sometimes it's , ha! nice try you manipulative fucker, and other times it's hang it all, your right, lets do the thing, now.....
the leson bieng, to be aware of everything, and one of those things is that try as you might, there are loose ends, which will unpredictably re prioritise everything, and the final proof of living well, is having the capacity to re prioritise, and then go on from there
and a child, or a dog, or a horse, will call your bluff
Fair critique, we should never lose the spirit of play, but Franklin’s guidance seems very much in line with a quote from Gustave Flaubert I often see echoed:
> Be steady and well-ordered in your life so that you can be fierce and original in your work
Genuine question: if you could tell Ben Franklin this, would you? I'm not even disagreeing with you, nor do I think there is a correct answer, but your answer and the reasoning behind it would genuinely interest me.
Sure I would. The conversation would go about as well as it would with any moral realist who believes he has identified the set of virtues or deontic norms which obligation would have us adhere to. I do not know if Mr. Franklin was a "serious man" as de Beauvoir described it, but these are certainly the same kinds of self-flagellatory ethics you would expect a serious man to have.
My interactions with such people usually reflect a piteous tone, as if it were a tremendous shame that I had not stopped for a second to think of the gravity of the situation. That is a necessary frame for them to hold given the preconditions which led to them
becoming a serious man.
while I like redhatting as much as anyone the interesting wrinkle to this criticism of franklin in particular is that this is much more like the way he actually lived than the principles he listed were. in fact, I dare say the only thing he missed on this list was making up for the non-existent sobriety of his youth.
"Franklin did not try to work on them all at once. Instead, he worked on only one each week "leaving all others to their ordinary chance." While he did not adhere completely to the enumerated virtues, and by his own admission he fell short of them many times, he believed the attempt made him a better man, contributing greatly to his success and happiness, which is why in his autobiography, he devoted more pages to this plan than to any other single point and wrote, "I hope, therefore, that some of my descendants may follow the example and reap the benefit."
> TEMPERANCE. Eat not to dullness; drink not to elevation.
"Not to elevation"? Let me direct you to the Finnish language. It contains two tightly related concepts: "nousuhumala" (ascending alcohol buzz) and the subsequent & corresponding "laskuhumala" (descending alcohol buzz).
If you recall the course of an evening of overindulgence, you may notice that these two concepts do describe the terrain.
AIUI these are from his autobiography, which he wrote during the last 20 years of his life. I wonder if he wrote this section before his decade in France? As I understand it, while there, he very intentionally led a life with little temperance, silence, frugality, moderation, and chastity.
This is a little disingenuous. As far as I know, v3 isn't going anywhere. There's what... weeks until May 2025, which would be four years?
4 years in JavaScript land is actually pretty long. Zod has a pretty good maintenance record. I don't see how a statement like yours can be made without snark. Calling it a "throw-away" library is pretty brash.
This looks like a good update that sticks to the formula.
> 4 years in JavaScript land is actually pretty long
For non-JS developers to get a sense of how long this is, companies have probably migrated from React to Vue to Svelte to Solid and then back to React in this time.
I just launched the beta for Table Slayer. It lets you build animated maps for in person RPG games (DnD, Pathfinder...etc) where you have a digital table top. It's built on Svelte + Turso + websockets.
The video here best shows it off. The source is available and free to use for non-compete, personal use.
I'm almost finished with a large, complex app written with Svelte 5, web sockets and Threlte (Three JS) [0]. Previously, I'd written React for about a decade, mostly on the UI side of things.
I vastly prefer Svelte, because of how clean the code feels. There's only one component per file, and the syntax looks and writes deceptively like vanilla JS and HTML. There's a bit of mind-warp when you realize Svelte doesn't want you passing components with props as props into another component. Svelte gives you "Snippets" instead, which work for some reusability, but are limited. It sort of forces simplicity on you by design, which I like. Most of React's deep nesting and state management doesn't exist in Svelte and is replaced with simple, better primitives.
The bigger gain though for me was Svelte(kit) vs. Next JS. It's very clear what is on the server and what is on the client, and there's none of that "use client" garbage with silly magic exports for Next JS things. The docs are great.
Svelte's biggest disadvantage is that the UI library ecosystem isn't as large. For me that wasn't as big of an issue because it was my expertise, but everyone else looking for a drop in UI library will find the Svelte versions a little worse than their React counterparts.
Because svelte is compiled, it also is by default very snappy. I think choosing Svelte would likely give most devs a speed boost vs. the spinner soup that I've seen most React projects become. A lot of that is going to be in the skill of the programmer, but I love how fast my app is.
Yeah, this is SvelteKit's biggest weakness. Easy to write code that seems to work until some unusual confluence of circumstances makes it run on the client when you've always tested it on the server, or vice versa, and it breaks. I still really like it for personal projects, but I think I'd want a clearer client-server separation for anything more complex.
Maybe things have changed now or I was just a bad react dev but the way hooks works kinda force you to have many child one-off components to not trigger rerenders in the whole component when only a small part was connected to that part of the State being updated. Having all these one-offs components in different files was painful.
Unfortunately some of us work with other people, and refusing to let them merge code we don't personally agree 100% with is a great way to stop working with other people :)
I also don't really see why this is a positive. If you have too much in a file, then split it off? It doesn't fundamentally add or subtract and complexity either way.
I think Svelte likely has a lot of benefits over React but I feel like this is a negative. It's easier for locally of code to keep related components together, and they can always be put into their own files later.
Big sharkdp fan. Ty you for making awesome software that i use DAILY.
bat, fd, hexyl, hyperfine
I'm going to take this moment to remind all of you well-paid engineers that if we each spread $10 a month sponsoring talented software makers like sharkdp the Internet would be a better place.
So many great little tools out there and we should try to support an ecosystem for them.
I owe hours of my life to Andrew Gallant aka BurntSushi's xsv. Nothing else tries to handle splitting long files into N-row chunks [1]. I was using the command line utility, but that's his wrapper around his rust-csv library. So if you need CSV parsing in rust, I strongly recommend this library.
[1] rows included linebreaks so your standard sed/head/tail/something-from-coreutils approach would not work.
I mean there are 131 open issues and some 30+ PRs, so clearly people have some desire for change.
No criticism to the author. He is way more productive than I will ever be, but xsv does appear to be on the back burner. Open source means the author can spend their time how they like and I am entitled to nothing.
readme says
this tool is originally a fork of BurntSushi's xsv, but has been nearly entirely rewritten at that point, to fit SciencesPo's médialab use-cases, rooted in web data collection and analysis geared towards social sciences (you might think CSV is outdated by now, but read our love letter to the format before judging too quickly). xan therefore goes beyond typical data manipulation and expose utilities related to lexicometry, graph theory and even scraping.
Was just going to say, the fd,bat author reminds me of burntsushi (xsv, rg), in terms of the massive benefit they've added to the *nix command-line ecosystem.
Astral is primarily funded by venture capital firms. The head honcho, Charlie, has mentioned a few times that he’d like to develop and sell services that integrate well with Astral’s open-source tools. However, nothing concrete has been established or announced yet.
I would not call that a tutorial on how to write good utility software. It's a quite specific description of how sub(1) was written, and it contains some useful lessons, but not many that would apply to the broad class of "utility software". I think.
in complete agreement, with tools like fd getting more visibility!
we sponsored fd's development a while back and we occasionally sponsor terminal tool authors from time to time at Terminal Trove where we have more tools in the trove. (0)
we're currently sponsoring zellij which I encourage you to check out and sponsor! (1)
It's like so many other projects we're talking about here: it has sane defaults. If you start Zellij for the first time, it shows you menus to do all the things you might want. A big plus is that it supports mouse scrolling by default, and the scrolling works 100% of the time as far as I can tell.
I don't know if it can do everything that tmux or screen can do. I bet it probably can't. But it does all the things I want such a thing to do, and without needing any configuration on my part.
Interesting. When I tried Zellij I found that the menus were too much in my face, compared to tmux/screen more minimal design. I see how this is a good thing when you start using it but I wonder if it gets tiring in the long run, in a clippy sort of way.
But yes it makes sense that this feature makes it superior to tmux for some users. A good case for having diversity in software.
I could see that. I use Emacs with all the toolbars etc turned off. I get it.
I’m not a hardcore tmux user. I just like having persistent sessions on remote machines and bouncing between tabs, things like that. When I want to do something beyond that, with tmux I’d have to RTFM each time. In Zellij, the menu bar lets me discover it easily.
Bottom line: you’re right. I’m glad they both exist!
I'm glad you identified the author -- I'm a big fd and bat fan but didn't know they were created by the same person. I'll have to check out his other tools.
I wish there was an easy way to find people to sponsor whose repos I use (not depend on because every project I use multiplies the same dependencies) but there are tools I use daily that aren't dependencies in my project like wezterm or atuin.
> For example, jumping to a specific position in a source code file, scrolling and clicking gets me there much quicker than navigating with the keyboard alone
I say this with the intention of providing context, not to say the way you do things is bad. It's all user preference in the end and there is no wrong way.
Lots of folks consider your "fast" example with a mouse as their "slow" example that forced them into learning more advanced features of their editor. For example. Most Vim users can get to any character or partial string, or parameter, or line, or paragraph, or function start or what you have within three quick keys on their home row. They do this quickly, and can immediately start doing other things right after because their hands never moved.
The mouse is fast because people don't need to memorize things. The keyboard is fast because the keyboard is fast.
It's like the old joke from the movie Heist. "What do you mean you don't like money? That's why they call it money".
No offence taken; there's always room to learn. Just curious, since I never use Vim, how exactly one navigates to (and/or selects) "aaa" part in the following string with just three keys in Vim?
That would be the generic vim way. I could mash on semicolon to get to each instance of "a" in the line. Here's another.
2fa
2 (2nd instance) f (find) (a)
Most people use a plugin called easy motion instead.
You type some two character key command to start it. For me it's "ff".
After ff, i type any two characters. It will then highlight each place in the document that start with those two characters (think an inline table of contents) that I can then select.
I write all this knowing it looks and sounds like madness, so again, don't take this as anything other than someone explaining their madness, but once you learn all this stuff (it takes about a month) you realize your mouse is actually the slowest way to do it.
Has anyone worked in a "two crews" system where there wasn't resentment? Or where people didn't want to naturally migrate to the "future crew".
I like the idea of this on paper. I have a hard time believing it can work in practice. The closest I've seen are library teams that build some service (say a design system + components) that other teams utilize.
At my last job we had a version of our on-prem product where the company sold a super extension for a version that was supposed to go out of support. We had a small team (I think three people) whose only responsibility it was to ensure that version was supported, pipelines worked and we're ready to ship a big fix at needed. That was their responsibility but as long as that was covered they were allowed to work in their spare time on what they wanted as long as they saw value for the company in it. It was a good bargain. Everyone else was grateful the small team was doing the dirty work and the maintenance team was delighted they could use the remaining time working on things that had always bugged them, do research, etc. This was a few years ago and I forgot details but I vaguely remember that we got some really cool improvements and research from them. The people on that team also were really excellent and self-motivating which helped make this a success but also more expensive.
> where people didn't want to naturally migrate to the "future crew".
I think the book captures a solution to this with:
> Engineers rotate between the crews on a regular basis. The Microsoft blog post referenced above recommends swapping some team members between the two crews every week.
> Define the customer crew as a temporary team. This can mean either that the customer crew itself doesn't exist full-time (perhaps for only one week per month), or that team members are constantly rotating between the customer and feature crews.
> Has anyone worked in a "two crews" system where there wasn't resentment?
yes. I've worked for a few places where the teams are fully distinct and it works well. In games think Engine team vs Game team. Even on the Game team at one of my previous roles the way it worked was you'd get put on a feature which might take 6-12 weeks to ship, and then there'd be some maintenance work/updates/tech debt after that. Your primary focus was the thing you just shipped but you'd also have the time to go back to some of the previous stuff and work on that too. During that time, the other team would be on the same rota, and after 6-8 weeks you'd on-ramp to a new feature and repeat.
I've experimented with a two-crew type system before (Red Team for feature development, Blue Team for stability and bug fixes).
Rather than treating these as fixed teams, we treated them as workstreams that people rotated between every sprint (every two weeks).
It worked for about 3 months, until it didn't - by then we had grown enough to organising the teams around the business capabilities or domains instead.
Sort of. I've worked with having a rota where engineers would spend a week handling support and bug reports which avoids many of the pitfalls with the entirely separate "two crews". I wrote a bit more about it in https://news.ycombinator.com/item?id=43337703#43339972 .
I would not want to migrate to the "future crew" given that "customer crew" getting enough resources (and adequately compensated). But even without separation it's typical that maintenance is starved while new features getting all attention and resources. I would guess separation on two teams would make it only worse.
