For context, SQLite4 explored reimplementing SQLite using a key-value store on log-structured merge trees, like RocksDB and Cassandra.
I'd be interested to hear why they stopped. Presumably reimplementing SQL on a KV store was seen as not worth it, when applications that are satisfied with an embedded KV store backend (which is much faster and simpler to write!) already have many options.
I find these “shorter work weeks are just as effective” articles to be nonsense, at least for knowledge workers with some tactical discretion. I can imagine productivity at an assembly line job having a peak such that overworking grinds someone down to the point that they become a liability, but people that claim working nine hours in a day instead of eight gives no (or negative) additional benefit are either being disingenuous or just have terrible work habits. Even in menial jobs, it is sort of insulting – “Hey you, working three jobs to feed your family! Half of the time you are working is actually of negative value so you don’t deserve to be paid for it!”
If you only have seven good hours a day in you, does that mean the rest of the day that you spend with your family, reading, exercising at the gym, or whatever other virtuous activity you would be spending your time on, are all done poorly? No, it just means that focusing on a single thing for an extended period of time is challenging.
Whatever the grand strategy for success is, it gets broken down into lots of smaller tasks. When you hit a wall on one task, you could say “that’s it, I’m done for the day” and head home, or you could switch over to something else that has a different rhythm and get more accomplished. Even when you are clearly not at your peak, there is always plenty to do that doesn’t require your best, and it would actually be a waste to spend your best time on it. You can also “go to the gym” for your work by studying, exploring, and experimenting, spending more hours in service to the goal.
I think most people excited by these articles are confusing not being aligned with their job’s goals with questions of effectiveness. If you don’t want to work, and don’t really care about your work, less hours for the same pay sounds great! If you personally care about what you are doing, you don’t stop at 40 hours a week because you think it is optimal for the work, but rather because you are balancing it against something else that you find equally important. Which is fine.
Given two equally talented people, the one that pursues a goal obsessively, for well over 40 hours a week, is going to achieve more. They might be less happy and healthy, but I’m not even sure about that. Obsession can be rather fulfilling, although probably not across an entire lifetime.
This particular article does touch on a goal that isn’t usually explicitly stated: it would make the world “less unequal” if everyone was prevented from working longer hours. Yes, it would, but I am deeply appalled at the thought of trading away individual freedom of action and additional value in the world for that goal.
I always love to see these projects attempting to create an Open-source parametric CAD tool, but I think they will never get the the level of functionality and stability required. The fundamental issue for all of them is the lack of a robust open source "parametric CAD kernel", these the the central core that understands BREP and implements the geometric operations.
The most widely used kernel is OpenCascade, the kernel used by FreeCad. However it is outdated, unstable and limited in significant ways with no realistic future prospects. It is unfortunately the limiting factor of FreeCads functionality and prevents any serious use of it.
The most widely used commercial kernel is Parasolid, used in many packages including SolidWorks, OnSpace, and NX.
What I would love to see is Siemens adopting a model similar to some of the game engines (Unreal and Unity) where it's free up until a revenue limit. Opening up Parasolid for "free" open source and small commercial operations would be both brilliant for society but also for Siemens, it would only result in a growth in the use of Parasolid and increased revenue.
import Mutex from 'lib/mutex';
class MyObject {
constructor() {
this.m = new Mutex();
}
async someNetworkCall() {
let unlock = await this.m.lock();
doSomethingAsynchronous().then((result) => {
// handle result
unlock();
}).catch((err) => {
// handle error
unlock();
});
}
}
let mo = new MyObject();
mo.someNetworkCall();
// The next call will wait until the first call is finished
mo.someNetworkCall();
I love it. We use it in our production codebase at Codecademy.
NixOS is the perfect OS for embedded Linux use, and I'm surprised that it hasn't seen any commercial uptake. I hope that some company adopts it for an IoT product or something so that it gets some love. I've been messing around on a Raspberry Pi and Beaglebone today with Debian, and I'm constantly frustrated having to use an imperative OS. I'm not using NixOS because even though it officially supports Raspberry Pi 3, I have not found it to be stable on that platform.
I'm excited about Mobile NixOS though. I've found the NixOS community to be motivated and friendly, but there is only so much progress that a small group of volunteers can make.
I'd be interested to hear why they stopped. Presumably reimplementing SQL on a KV store was seen as not worth it, when applications that are satisfied with an embedded KV store backend (which is much faster and simpler to write!) already have many options.