If this were in a Commerce Clause context, Congress' decision not to act on a given matter still wouldn't allow the states to restrict or legislate on interstate commerce, by the principle of the "Dormant Commerce Clause".
By analogy, I could imagine a "Dormant Copyright Clause" doctrine, meaning that the states shouldn't have the power to legislate copyright other than in whatever contexts the Federal government explicitly leaves to them.
This is all theory, of course. But actual case law does say something at least similar. See for instance Sears, Roebuck & Co. v. Stiffel Co., a case in which the Supreme Court said (in the context of patents) that the Constitution reserves the power over them to the Federal Government exclusively, and that the states can't give patent protection to something that Federal law doesn't protect.
>other than in whatever contexts the Federal government explicitly leaves to them.
This is what Congress did when passed the ~1978 legislation (even if somewhat retroactively, based on your dormant commerce argument). It explicitly affirmed existing state law for previous recordings, while declaring exclusive Federal jurisdiction for the future.
The original post does talk about it, but it skips the basics, presumably on the assumption that they're already known.
> will the Linux kernel automatically start using RAM as disk cache if there's enough free space?
Yes, exactly.
> Is it smart enough to prioritize disk cache over infrequently used pages and then know to discard the disk cache if it does need to page stuff back in from swap?
It is, and this is what's controlled by the vm.vfs_cache_pressure sysctl that the post discusses how best to configure.
You can license your project however you would like to. You absolutely can have a license with text that is similar to the MIT license, except with a clause saying that company X can't use it. However, as other commentators here point out, you could not, in good faith, call that "open source" under the standard, accepted definitions of that term.
So the answer to "is there any way to achieve this?" is twofold. If the question is "can I achieve this and still legitimately use the term 'Open source software'?", the answer is a flat-out "no". If the question is "can I set it up legally in this way, without regards to the terminology", the answer is yes.
A license is a pretty free-form thing. You can write whatever text there you want. You may wish to consult with a lawyer, in order to get some legal assurance that what you wrote makes legal sense and will hold up in court. This is especially true if you want to be very sure that you didn't accidentally leave some loophole in your wording that will allow the company you dislike to use your project against your will.
You are going to have to write the text of this license yourself (or pay a lawyer to do it for you): you're not going to find much of this kind of "almost-OSS" license out there for you to base yours off of, because in general, those who want to license their software as OSS actually do want a fully OSS license. But there are a few examples, although not quite identical in spirit to your "use case" (excluding a particular company) but instead different variations of not-quite open source. For instance, you can take a look at MongoDB's SSPL (https://www.mongodb.com/licensing/server-side-public-license), and Redis Lab's RSAL (https://live-redislabs.pantheonsite.io/wp-content/uploads/20...).
Thanks a lot for going into details. Since then I learned a lot about copyleft, GNU GPLv3, and much more. Maybe mentioning a company name in a licence is not really what I need after all.
It is true: right at this very moment, billions of people have enough food do eat. It is a worthy task to try to extend that to the hundreds of millions who are not there yet, but it's hardly something that has never been done before, unlike driverless cars.
That doesn't mean it will be any easier (or harder), but it does mean that it is less of a "moonshot".
Yah, it might also be different connotations on moonshot. If you believe a moonshot has to be something new + unlikely/hard then it's definitely not a moonshot. If you think a moonshot is something that's just incredibly unlikely but potentially super valuable, it definitely is.
Empirically, at least two investors who had put money into successful early-stage driverless cars and one who put money early into Planet Labs thought what we were doing was going to be harder. For some VCs, Africa might as well be the moon.
To me one implication of a moonshot is that you're aiming to hit a small target, and a miss is a miss no matter how close you get.
You made "end[ing] human hunger for a few hundred million people" your goal, but it isn't the case that anything short of that equals complete failure. Even if you only got a fraction of the way that'd be a massive success in my view.
Here’s a quick question, what makes you think it’s the lack of technology that is the cause for poor farming yields? What makes you think it’s not due to property rights and rule of law?
If you went 50 years in to the future and came back with X widget for farming and just dropped it in random place in South Sudan or Niger, I don’t think they would just become farming power houses.
When we talk about basic ag tech, we're not talking about drones or robots, we're not even talking about mechanization, it's mostly fertilizer and seed breeding.
- The accumulated knowledge of crop science is pretty strong, it's not a secret what the limiting factors in cereals crops are.
- Empirical results (see groups like The One Acre Fund, extensive research farm results in the region, high confidence RCTs leave basically no doubt)
- For US farmers prior to ~1930, they had the same average yields as Kenya does currently. In fact, fertilizer usage and yield have a very strong correlation and Kenya has a very similar curve.
Are there factors besides inputs that can impact yield? Absolutely. You could see from satellite imagery the places where conflict reached in Syria by harvest time as that conflict was developing. Market access and infrastructure in Kenya are super hard also, fertilizer is more expensive in rural Kenya than it is in the United States even though the consumers are much poorer.
Basically, there are certainly places that we're not a good fit for. I don't think we could operate in places with active conflicts like South Sudan, but Africa's a real big place. Kenya is quite stable and has effective if not formalized property rights for most smallholders. The thing I always try to remember is that America had very similar problems. The area that is now the great bread basket of the world also used to be referred to as "The Wild West."
That doesn’t address the core issue of rule of law and property rights though. Pick any number of countries in Africa and air drop them ag-tech that’s 50 years into the future. I don’t for a second believe that it would cause much of anything to change or improve.
Your US example appears to have been constrained by the current tech and knowledge of the day. In Kenya like you bring up, they aren’t limited by those things but rather lack of rule of law and property rights. So how can you compare them apples to apples?
This isn’t a chicken or egg thing. Rule of law and property rights are the necessary condition to allow people and society to grow and flourish. You can’t skip those necessary steps.
I mean look at the agricultural output for Zimbabwe for reference.
Hey, I'm sorry but I truly don't understand what you're trying to say. I want to try and understand where we disagree, because to me that usually indicates we're having a communication failure. I think this is an empirical question and I feel like it's been settled at every level, and so I'd like to understand at what level we're disagreeing.
Things I believe:
- At the plant level, crop science has shown fertilizer and seed breeding are by far the dominant factor that control the first 75% of yield above wild types of maize/corn.
- One Acre Fund RCTs have shown that providing seed and fertilizer substantially improve yield outcomes.
- At the macro level, the development path of most countries that have transitioned out of agricultural economies have correlated extremely well with fertilizer usage. From the US to China, yield correlates really, really well with fertilizer usage and minimally with things like rule of law indexes of property ownership.
A simpler variation of the same concept is to use the fact that for every expression `expr`, `do expr` is a valid expression, allowing you to start a sequence with any number of `do`s.
But the challenge as I see it is to stack as many distinct keywords in a row. In javascript you can do the same thing with `await`: for every expression `expr`, `await expr` is a valid expression, so you can start with a sequence of any number of `await`s. That's great, but ultimately not a challenge: the real puzzle is in stacking as many unique keywords as possible.
If you are asked that question this is the sort of answer you give:
"I was given an opportunity to lead a product I was very excited about, and I took it. It was a great experience, and I learned a lot, but ultimately now I'm glad to be moving back into a developer role."
If you can truthfully say that, you're conveying not indecision, but rather showing the flow of your career path. That is something that is expected to take a few twists like this, and that's even a sign that you're someone with flexibility and a variety of skills, as opposed to being inflexible and unwilling to do things that are "outside the box".
And if you have leadership experience, you could always step back into that role if the needs of the company change (e.g. project lead leaves the company and they need someone to fill in until they get a replacement).
My previous company saw project management as a step up, whereas I see it as just another role. Many engineers make poor project leads, and many project leads make poor engineers. Unfortunately, our society values "people" jobs like leadership positions more than technical jobs, so people will see it as a downgrade (especially those in management).
Ignore that noise and do the thing you like that helps you meet your other goals (financial, lifestyle, etc).
The answer is very much "practicality issue". Haskell's more advanced type level features (including GADTs and type families) are very much suited for this, but they're also the sort of thing that gives Haskell a reputation for being complicated. If your just using Haskell's core features the way the parent post does, Haskell is a very simple, very elegant language.
But better yet, it certainly does have the big guns which you can pull out.
-- Just like before, we define `Class` and `Weapon`:
data Class = Warrior | Wizard
data Weapon = Sword | Staff | Dagger
-- The one really annoying thing is that
-- at the moment you have to use a little bit
-- of annoying boilerplate to define singletons
-- (not related to the OOP concept of singletons, by
-- the way), or use the `singletons` library. In the
-- future, with DependentHaskell, this won't be necessary:
data SWeapon (w :: Weapon) where
SSword :: SWeapon 'Sword
SStaff :: SWeapon 'Staff
SDagger :: SWeapon 'Dagger
-- Now we can define `Player`:
data Player (c :: Class) where
WizardPlayer :: AllowedToWield 'Wizard w ~ 'True => SWeapon w -> Player 'Wizard
WarriorPlayer :: AllowedToWield 'Warrior w ~ 'True => SWeapon w -> Player 'Warrior
This last part shouldn't be to difficult to understand, if you ignore the SWeapon boilerplate: Player is parameterized over the player's class, with different constructors for warriors and wizards. Each constructor has a parameter for the weapon the player is wielding, which is constrained by the type family (read: type-level function) named AllowedToWield.
AllowedToWield isn't that complicated either, it's just a (type-level) function that takes a Class and a Weapon and returns a `Bool` using pattern matching:
And there it is. What do you gain from all this? Something which it is very had to get in certain other languages: compile-time type checking that there is no code that will allow a wizard to equip a sword, or a warrior to equip a staff.
Once again, I want to make it clear that you absolutely don't need to do this, even in Haskell. You're absolutely allowed to write the simple code like in the parent post. But in my opinion, this is an extremely powerful and useful tool that Haskell lets you take much further than many other languages.
So long story short, the answer to your question is that it is indeed a "practicality issue", although I don't think that my code is that impracticable. It certainly is absolutely not a Haskell limitation: in fact if anything, Haskell makes it a bit too tempting to go in the other direction, and go way overboard with embedding this kind of thing in the type system.
Thanks for the detailed explanation! I'm mostly a dynamic languages programmer, but I've been reading (and enjoying) Type-Driven Development with Idris, and I have a plan to learn Haskell after that. If such a relationship wasn't modellable, I'm not sure I would have bothered after all.
