Logseq, it's geared to daily notes and visualizing everything in a graph, and support KaTeX. It also supports org-mode. If it fits your workflow I'd recommend it. Personally I feel like Obsidian does too many things and none too well.
This locks up your money in the meantime, right? If so, considering the fed funds rate is 3.64% (and you can probably get higher rates on stablecoins), a huge chunk of those "winnings" is going to be eaten up by the opportunity cost of the money.
You forget that Polymarket is just a casino, and the house always wins.
For example, recent events show that any bet can be selectively disputed by arbitrary reason ("we found insiders", "we found this immoral/illegal", etc.).
Whether it's pennies in front of a steamroller will depend on the entry price, EV, time left to resolution and many other variables.
Though I agree it's bad math, even if 70% resolve to no, there's a high variance among all of them, and to know whether it's a good bet or not... you have to do your DD on that particular market. Even if you follow the Kelly criterion, randomly choosing bets will probably tank your bankroll sooner or later.
> Whether it's pennies in front of a steamroller will depend on […] many other variables.
No, all these variables cancel out.
If you were picking and choosing, yes. But this approach is basically betting no on all the markets.
The textbook explanation of this is the central limit theorem, proving this mathematically is a bit more involved for power-law systems like this but it’s empirically valid.
The reasoning behind Gentan was that a landless peasantry was more likely to revolt. It's not dissimilar to pre-1929 kulaks, though the kulaks were encouraged/enabled to become a relatively wealthy/middle class peasantry who employed people and were directly involved in the production without owning large swathes of land, acting as a kind of a social dampener against a revolution.
Unsurprisingly the Soviet Union killed the kulak model and moved to collective farming[0], which was arguably actually communistic.
Kulaks were the stated problem, the real problem were the middling farmers. If you're a smallholder with a surplus of land, your production is very elastic.
You can plant cash crops and sell them to buy industrial products. Or you can plant crops that boost your quality of life directly: fruit, vegetables, tobacco, animal fodder.
The "price scissors" (low price of wheat, high price of goods) meant that middling farmers stopped planting wheat that the USSR needed to feed the cities and to pay for imports. To make the peasants plant wheat again the Soviets took away their land in the name of economy of scale (collectivization), but the real goal was to limit the size of personal plots.
> The reasoning behind Gentan was that a landless peasantry was more likely to revolt.
So, it was an anti-revolutionary policy. Which at that time of history worked as well as an anti-communist policy.
> Unsurprisingly the Soviet Union killed the kulak model and moved to collective farming[0], which was arguably actually communistic.
Soviet Union, whatever it had preached, implemented state capitalism - concentration of the means of production under a single owner.
It's important for me to use words precisely. If somebody implies, for example, that capitalism is the opposite of communism, that's just snatching the words and waving them like banners.
>Soviet Union, whatever it had preached, implemented state capitalism - concentration of the means of production under a single owner.
Lenin preached for state capitalism as a transitory state towards socialism. It's an integral part of the communist ideas, part of the direction even if not part of the ideal final state.
Sure. Historically, at times people had free trade. At times we had no monopolies at all. At times there were really few laws. We had democracy and free speech and more. Various components of "The West" had been tried before.
All these did not compare with the sheer effect of capitalism: let's concentrate the production, let's scale it so big that every worker will become a hyper-narrow specialist. You bet it's unsexy take today, but it was universally understood in Lenin's times that it's a path not possible/feasible to withdraw from. That's the one magic ingredient that seems absolutely required.
In terms of the usual data collection, I'm very happy with TrackerControl[0]. It's basically meant to run as an always on VPN (it isn't one) which allows it to block ads, social media, trackers, etc with quite reasonable granularity. I'm surprised at the amount of apps that fail to work correctly unless they have access to their data harvesting endpoints.
In terms for pure access to the data/permissions, GrapheneOS seems to be the main (only?) choice. The default permissions apps get in current day Android allow to group activities and tie them to a single user across apps/sites.
Something worse than a bad model is an inconsistent model. One can't gauge to what extent to trust the output, even for the simplest instructions, hence everything must be reviewed with intensity which is exhausting. I jumped on Max because it was worth it but I guess I'll have to cancel this garbage.
With Claude Code the problem of changes outside of your view is twofold: you don't have any insight into how the model is being ran behind the scenes, nor do you get to control the harness. Your best hope is to downgrade CC to a version you think worked better.
I don't see how this can be the future of software engineering when we have to put all our eggs in Anthropic's basket.
There's already a bunch of comments about Nix, so I don't want to repeat them, but really Nix is less complex than a handcrafted series of Makefiles, and significantly more versatile.
With home-manager I have the same packages, same versions, same configuration, across macOS, NixOS, Amazon Linux, Debian/Ubuntu... That made me completely abandon ansible to manage my homelab/vms.
Also adding flake.nix+direnv on a per project basis is just magical; I don't want to think how much time I would have wasted otherwise battling library versioning, linking failures, etc.
"This problem has already been solved in Canada. Just move to Canada."
Make is generic. Nix is not.
Before I even look at the actual code I already know that it is something I can use immediately on my existing system, no matter what that happens to be, right now, without changing anything else.
It doesn't matter how great nix is because it's not alpine or xubuntu or suse or freebsd or sco osr5 or solaris or cygwin, it's nix.
Even if you're only talking about nix the package manager, or nix the language, and not nix the os, it actually still applies because Make is everywhere and nix is not.
Even if this thing has bash-isms and gnumake-isms, I bet with minimal grief I can still use it on a Xenix system that doesn't even have a compiler (so no building nix) but does have ksh93 and make, even without leaning on the old versions of actual gnu make and bash that do exist.
>Make is generic. Nix is not. Before I even look at the actual code I already know that it is something I can use immediately on my existing system.
Hard disagree on this one. It's a series of makefiles that depend on apt (or whatever pacman you choose), so for any heterogeneous environment it's going to constantly be uphill battle to keep working in terms of package naming, existence of dependencies, etc. You'd find yourself reinventing Ansible, but worse.
> It doesn't matter how great nix is because it's not alpine or xubuntu or suse or freebsd or sco osr5 or solaris or cygwin, it's nix.
Nix runs fine on most (all?) modern Linux distros, macOS, even WSL, and there are workarounds to make it run on BSD, though I admittedly haven't tested those.
> Even if this thing has bash-isms and gnumake-isms, I bet with minimal grief I can still use it on a Xenix system that doesn't even have a compiler (so no building nix) but does have ksh93 and make, even without leaning on the old versions of actual gnu make and bash that do exist.
Use it on Xenix (which last shipped in 1991) to do what? The package management was tarballs and compiling. Instead of reinventing Ansible, you'd be reinventing pkgsrc. Not sure what your point here is.
Where I grew up, it happened to me with (primary/middle/high) schools.
During the 60s and 70s, in order to accommodate baby boomers, new buildings were built on existing school grounds, and while they were not cookie cutter copies of each other, they followed the same architectural and civil engineering principles: identical ceiling height, same fixtures, same walls, same classroom door arches, same bathroom stalls, toilets, similar fire exit paths, identical heavy steel and steel wired glass external doors, staircase layouts...
But given every location had its own available surface and urban/terrain/attendance needs, they were anywhere from 1 to 4 floors, straight corridors, or in L, or rectangular with inner courtyard, with and without basement, and overall significant practical deviations from some common standard blueprint (though I never found the common denominator) but keeping everything else the same. It was extremely eerie and disorienting visiting a different school, or getting used to another school when you moved, especially after hours when they're empty.
It's probably similar to the khrushchyovki/stalinki residential buildings in post-Soviet countries, though I've only visited them well after the collapse and they've evolved on their own. Meanwhile these schools I mention, look actually frozen in time.
reply