ezst

14 ms·

211.
by ezst 6mo ago
Funny, I have it exactly the other way around!
212.
by ezst 6mo ago
Not op but that's missing the forest for the tree. Those devices are not meant to be e-waste conscious at all, which is the undertone here: you can't replace the battery yourself, you can't expand storage when you need, you c
213.
by ezst 6mo ago
Exactly, "automate your WhatsApp/Signal/..." sounds like "use XMPP for that use case", that's my go-to for bots and notifications, it works as well if not better, and I sleep better at night.
214.
by ezst 6mo ago
Cory Doctorow made a whole CCC speech about this.
215.
by ezst 6mo ago
not OP, and indeed git is fast-enough in many cases, but git not cutting it at Google and Facebook scale, combined with the versatility of mercurial (monkeypatching and extensions system) was the reason why they both invested heavily in mer
216.
by ezst 6mo ago
> I think there are (or perhaps were) some product issues regarding the specifics of various workflows. I love jumping in discussions about git branching, because that's a very objective and practical area where git made the playing
217.
by ezst 6mo ago
> one that they're able to represent in Git's model, with Git's features. They're even able to do it without exposing me to it. But the same isn't true in reverse. Strictly superior? not sure what you mean to say
218.
by ezst 6mo ago
I'd like to fill up some inaccuracies in your response: - rebasing in Mercurial simply means chopping a subtree off of the history and re-attaching it to a different parent commit. In that sense, rebasing is a very useful and common hi
219.
by ezst 6mo ago
Or subsidize nuclear because it complements beautifully solar & wind as cheap and clean energy?
220.
by ezst 6mo ago
Or the plethora of languages compiling to WASM, for that matter
221.
by ezst 6mo ago
> Are we back to "programming language X is slow" assertions? thought those had died long ago. Yes we are? The slow paths of mercurial have been rewritten in C (and more recently in Rust) and improved the perf story substantial
222.
by ezst 6mo ago
This isn't an apology or a deflection, but different VCSes strike different trade-offs in terms of speed per workload. The mercurial storage model is comparable to video encoding in that it has a somewhat equivalent of "key frames
223.
by ezst 6mo ago
Every success story and happy conversion to jj is evidence that hg should have won the DVCS war, but more importantly, that VCSes and their inherent merits and tradeoffs were always secondary to the social networks underpinning them. GitHub
224.
by ezst 6mo ago
Wasn't CATIA running on unix even before it ran on Windows?
225.
by ezst 6mo ago
I obviously don't have a horse in this race, but this seems... more correct this way? And with Holland being a region (or two) and not the majority of the territory, how do the Dutch not living in Holland feel about it? It would seem l
226.
by ezst 6mo ago
Why not?
227.
by ezst 7mo ago
Or you were just reading confabulations, without a way to tell, corrupting your knowledge in the process. In general, I believe the problem of our time (sociopolitical divide, echo chambers, propaganda, people getting pulled to extreme view
228.
by ezst 7mo ago
Have you tried paperless-ngx, a true and tested open source solution that's been filling this niche successfully for decades now?
229.
by ezst 7mo ago
> Why we need these careful thought, abstraction and architecture? your answer focused on maintainability, but you are overlooking what I think is the bigger problem: those components will eventually interact with one another (technicall
230.
by ezst 7mo ago
I can totally wrap my head around that, and it's an interesting thought experiment, though: - building functionalities as components that are swappable on a whim requires a level of careful thought, abstraction and architecture that es
231.
by ezst 7mo ago
Any mid- to high-end pro-line laptop from the usual manufacturers (dell latitude series, lenovo T series, hp pro/elitebook series) gives you that, really (rigidly built body using magnesium/aluminum alloys, good input devices and
232.
by ezst 7mo ago
That people on this forum convinced themselves that it's a reasonable take to vibe code a useful geometric kernel is profoundly depressing.
233.
by ezst 7mo ago
I haven't used a laptop in the last decade that wouldn't last a whole day on battery, or would hold any of those qualifiers for that matter, from Apple or other manufacturers. Not that Apple are bad devices, but they are flawed li
234.
by ezst 7mo ago
> After I got used to working in windows instead of full screen all the time, I can't really go back. Sorry if this comes across as disrespectful, but it smells like Stockholm Syndrome. You are choosing not to use the full extent of
235.
by ezst 7mo ago
I don't understand how we keep hearing so often here about Apple OSes being so amazingly simple, approachable and cleverly designed with a lot of attention paid to detail, while every practical productivity advice involves some undisco
236.
by ezst 7mo ago
>> This was costing us ~$300K/year in compute, and the number kept growing as more customers and detection rules were added. > For something so core to the business, I'm baffled that they let it get to the point where it
237.
by ezst 7mo ago
Probably the one elephant in the roomy thing that matters: failing to say they don't know/can't answer
238.
by ezst 7mo ago
it seems indeed better in some ways, but the scoring is still way off, for example, for my second criteria: > - works on partial matches (e.g. inputting "ma in" matches ("make install", "cd main") typing &qu
239.
by ezst 7mo ago
I never found a satisfying search algotithm with atuin (iterating over time between fuzzy, skim, fulltext, and maybe others). Is there one that is both: - case insensitive (e.g. inputting "make" matches ("make install",
240.
by ezst 7mo ago
Wouldn't a solution be to have the opening on the side and pull it toward you, like a "box on wheels"? As long as the sides of the "box" are thermally insulated, it seems like a sound solution for the stated problem

More ›