I've had exactly the same thought, after hitting walls repeatedly with limitations in single-language ecosystems. And likewise, I've had the same concerns around the complexity that comes with Bazel/Buck/Nix.
It's been such a frustration for me that I started writing my own as a side project a year or two ago, based on a using a standardized filesystem structure for packages instead of a manifest or configuration language. By leaning into the filesystem heavily, you can avoid a lot of language lock-in and complexity that comes with other tools. And with fingerprint-based addressing for packages and files, it's quite fast. Incremental rebuild checks for my projects with hundreds of packages take only 200-300ms on my low-end laptop with an Intel N200 and mid-tier SSD.
One other alternative I know of that's multi-language is Pants(https://www.pantsbuild.org/), which has support for packages in several languages, and an "ad-hoc" mode which lets you build packages with a custom tool if it isn't officially supported. They've added support for quite a few new tools/languages lately, and seem to be very much an active project.
Not what I said. I said that, sub-dividing days is not really simpler with base 10, and that sub-dividing time is pretty important practical aspect of time-keeping.
I do. I sleep 8 hours, wake up 2 hours before work, work 8 hours, and spend 6 hours in the evening afterwards. That's 1/3, 1/12, 1/3, and 1/4 of the day, or 3.33, 0.83, 3.33, 2.5 decimal hours.
You have a good point about taking it in context with the 'decimalization' of other units of measure, but my point is really just that the article is overly generous towards decimal time, and ignores solid mathematical reasons for using 12/24/60 for time-keeping. I've never in my life needed to know when a day is "70% over", but I constantly need to subdivide my time into halves, thirds, or quarters.
Fun little snippet of history =), but something that seems to get missed often in time-keeping is that 12, 24, and 60 are not accidental, they're used for a good reason - they're highly divisible numbers.
12 is divisible by 2, 3, 4, 6
24 is divisible by 2, 3, 4, 6, 8, 12
60 is divisible by 2, 3, 4, 5, 6, 10, 12, 15, 20, 30
Compare that to
10 (divisible by 2, 5) and
100 (divisible by 2, 4, 5, 10, 20, 25, 50),
and you start to see the problem. You can't split a 10 hour day into quarters without a decimal, and you can't split a 10 hour day into thirds without an infinite decimal or a fraction.
"
But in 1793, the French smashed the old clock in favor of French Revolutionary Time: a 10-hour day, with 100 minutes per hour, and 100 seconds per minute. This thoroughly modern system had a few practical benefits, chief among them being a simplified way to do time-related math...
"
isn't really true. Sub-dividing days and hours into smaller, equal pieces is a critical part of time-keeping, and it really isn't simpler with 10 and 100.
I'd like to throw my two cents in here: strength training.
I started having problems with RSI about five years ago, and I tried and failed to get relief from quite a few different things, including the Mindbody Prescription, but what ultimately helped me the most was arm and grip exercises: pull ups, deadlifts, farmer's walks.
If you're going to do _anything_ for 8 hours a day, even sitting, you should be taking measures to make sure it doesn't impact your health.
Good article! I find CPS rather refreshing to work with in JS; so much so, that I prefer using it for asynchronous code over promises or async/await. It turns out 'callback hell' isn't so hellish with a few simple conventions, and I feel that functional-style asynchronous code is much easier to get right than imperative-style asynchronous code.
If you want to get excited about UBI again , consider the opposite action:
Take the US, and instead of giving everyone in the country 10,000 USD/year in UBI, take 10,000 USD away: add a new 10,000 USD/year flat tax.
Do you still think all prices will re-stabilize, and everyone will end up _exactly_ the same as before? Or, isn't likely that taking 10,000 away from a poor man will hurt more than taking 10,000 away from a rich man?
So, intuitively, wouldn't giving every person in the US 10,000 USD help the poor more than the rich? Where's the evidence to suggest all of that money would immediately be swallowed up by cost inflation?
Of course, the effect in reality will be a little more complex, and hard to measure, but I'd argue that intuition suggests UBI, by nature, _has_ to help fight inequality, just like free education, free healthcare, nationalized insurance, and any other progressive services that give equal benefits to all citizens. The question isn't if we should try it, but how much should we give.
Yes, its a living language. But, it makes everyone's life just a little bit harder when you try to co-opt a very old word, with a very clear definition, for your latest fiat currency.
Don't be a dick to mathematicians around the world. Just say 'cryptocurrency'.
2. They do account for temperature, by comparing geographically close cities with different activity inequality levels.
3. They do account for "cost". They repeatedly compare cities and countries with roughly the same income distributions.
Also, as far as I can tell, the paper draws _exactly_ the opposite conclusions as what you state. In no way do they claim that rich people exercise more, nor do they claim that demographics have a strong correlation with exercise.
From what I read, they come to two conclusions:
-There is a correlation between activity inequality and obesity.
-There is a negative correlation between activity inequality and walkability.
Native install for me. I can't compare it with crouton, as I've never even really used ChromeOS. The first thing I did was replace it with Debian. I'm pretty happy with what I have now, though. Everything works out of the box with Arch.
If you're on the fence about going native, you should do what I do: install arch on an SD card and boot from that. Good SD cards these days are plenty fast too, and if you like the native system, you can keep using it from the SD card, or use it to install Arch on the SSD. Just make sure you get an SD card with TRIM, and it'll work fine for long-term use.
I've been using a Chromebook Pixel (64GB version) as my primary work machine since I received it in 2013, first running Debian and now Arch. You'd be surprised at how well it's held up:
-It only has 4GB of RAM, but that's been enough up to now. Most builds are I/O bound anyway, and the SSD is fast.
-I don't use an external monitor, as the high pixel density of the screen more than makes up for the small size.
-The 64GB can be limiting, but in some ways its been beneficial, as its forced me to actually pay attention to backups.
-These days, if I have a long-running/high-resource process, I just spin up a VPS and run it there.
I think Google was pretty prescient with the Pixel laptops. When this one isn't enough, I'll be upgrading to the 2015 model.
Hey, I used to work with their CTO! Hopefully he'll respond himself, but in case he doesn't:
> (384-bit prime) - Why not just use X448 since that's now an Internet Standard?
I believe they started working before X448 was standardized.
> It also uses Fortuna for IVs, etc. instead of directly /dev/urandom (or window.crypto in JS land). Userspace CSPRNGs are a devastatingly stupid idea.
IE doesn't have great support for window.crypto. If you're building an enterprise product, you probably care about this.
> FUD. Where you host the data shouldn't matter, because the server should never be given access to your plaintext.
I believe their point here was that most cloud services today DO have access to your plaintext. It's not FUD if it's true =).
I know I'm a bit biased, but these guys are pretty smart, and I'd trust them.
I agree! There are quite a few provably insecure algorithms in the project. That said, I do think they are useful to keep around: As a reference, for legacy systems, or to practice cracking.
It'd be a little silly to not add AES-256 since I already have AES-128, but I will definitely look into adding CAST5 and CSPRNGs.
It's been such a frustration for me that I started writing my own as a side project a year or two ago, based on a using a standardized filesystem structure for packages instead of a manifest or configuration language. By leaning into the filesystem heavily, you can avoid a lot of language lock-in and complexity that comes with other tools. And with fingerprint-based addressing for packages and files, it's quite fast. Incremental rebuild checks for my projects with hundreds of packages take only 200-300ms on my low-end laptop with an Intel N200 and mid-tier SSD.
It's an early stage project and the documentation needs some work, but if you're interested: https://github.com/somesocks/dryad https://somesocks.github.io/dryad/
One other alternative I know of that's multi-language is Pants(https://www.pantsbuild.org/), which has support for packages in several languages, and an "ad-hoc" mode which lets you build packages with a custom tool if it isn't officially supported. They've added support for quite a few new tools/languages lately, and seem to be very much an active project.