FBT

If one were to use a fairly standard number for the statistical value of a human life, $10MM, then $126MM is about the same amount of harm as the deaths of 12.6 people.

(You have to choose some number as the value of a human life, and the power of the "statistical value" measure is that it is self-determined, derived from the choices people make for themselves of how much money to pay to reduce the risk of dying, aggregated and averaged. You are free to advocate for a different measure, but if so, you need to actually make the argument, ground your measure in something, something that you then need to claim is a better measure than people's own revealed preferences.)

7 USC § 1a(37) defines an "organized exchange" as

> [A] trading facility that— (A) permits trading— (i) by or on behalf of a person that is not an eligible contract participant; or (ii) by persons other than on a principal-to-principal basis; or (B) has adopted (directly or through another nongovernmental entity) rules that— (i) govern the conduct of participants, other than rules that govern the submission of orders or execution of transactions on the trading facility; and (ii) include disciplinary sanctions other than the exclusion of participants from trading.

And 7 USC § 1a(51)(A) defines a "trading facility" as

> [A] person or group of persons that constitutes, maintains, or provides a physical or electronic facility or system in which multiple participants have the ability to execute or trade agreements, contracts, or transactions— (i) by accepting bids or offers made by other participants that are open to multiple participants in the facility or system; or (ii) through the interaction of multiple bids or multiple offers within a system with a pre-determined non-discretionary automated trade matching and execution algorithm.

(7 USC § 1a(51)(B) then follows with some exceptions to that definition.)

In short—an "organized exchange" is defined as a type of "trading facility". To count as a trading facility", whether of the "organized exchange" type or not, you must either accept bids or offers from other participants yourself or else deterministically match and execute those bids and offers.

The Magic: The Gathering card "Blood Moon" was first printed in 1994. It seems quite unlikely that the term was invented some twenty years later.

> ... Does distributivity of inversion ~ over operation ⋆ follow from the other Abelian group axioms / properties? If so, how?

It does. For all x and y:

  (1) ~x ⋆ x = 0 (definition of the inverse)
  (2) ~y ⋆ y = 0 (definition of the inverse)
  (3) (~x ⋆ x) ⋆ (~y ⋆ y) = 0 ⋆ 0 = 0 (from (1) and (2))
  (4) (~x ⋆ ~y) ⋆ (x ⋆ y) = 0 (via associativity and commutativity)

In (4) we see that (~x ⋆ ~y) is the inverse of (x ⋆ y). That is to say, ~(x ⋆ y) = (~x ⋆ ~y). QED.

In a negotiation, the goal is to reach an accommodation suitable for both parties. If the web developer doesn't want to set up his server on port 80 to serve HTTP, that's his business. Your user agent is still working for you, when it negotiates with the server what protocols it will accept. (It also negotiates a content type for the response; and if all the server has is static HTML, it's not your user agent's fault if what you get is HTML, even if you really wanted some other format. Take it up with the web developer, if you want the data in some other format. The browser is just doing its best for you.)

Your argument makes sense in one narrow circumstance which is not the typical HSTS setup: if the server is serving the site with plain HTTP on port 80 (and not just a redirect to the HTTPS version of the page), and also has a HTTPS version with HSTS headers. (So that the first time you visit the HTTPS version, your browser will insist on taking you to that version every time.)

Asterisk magazine (https://asteriskmag.com/) is the only site I know of that does the thing that the author couldn't find an example of with a progress bar that includes section headings (on hover) and thus shows your progress through the table of contents. On mobile, where there is less space, it falls back to just being an ordinary progress indicator.

> There aren't nearly enough capacity in the judicial branch to handle all that work.

Then appoint more Article 3 judges. It could even be the same people who are now "administrative judges"—but take them out of the executive branch hierarchy, and give them the independence that the constitution requires judges to have.

The problem is that while it's an impressively close approximation for an off-the-cuff guess (at least if we charitably translate his "dozens"/"dozen" to 12), to the extent it was pre-planned it's a terrible approximation. ~50 years as a lifetime is the right order of magnitude (and thus a very good result for a guess), but is too far off to be any good if precalculated.

There are about half a million minutes in a year, so 50 million seconds is a year and two thirds. At the rate of saving 50 million seconds a day, in a year you'll have saved around 608 years—which is only a dozen lifetimes if a lifetime is around 50 years. Still, that's a pretty close approximation for an off-the-cuff guess.

> own build system

Nothing in Rust requires you to use Cargo. It's really convenient to have a good build system like Cargo—but if you like C style of manually invoking the compiler, rustc can do that too.

Rust is no worse by bundling Cargo. It strictly dominates the alternative, which would be to just ship rustc and allow the user to pick whatever build system they like. You still can pick your favorite build system; but if you don't have a particularly strong preference, Cargo is a very good default.

When it comes to the systemd logs, this is kind of what the -x flag to journalctl does (or tries to do.)

Having detailed human-level descriptions of what's going on and how to fix it is great. But you also don't want to drown out any important details under waves of verbose text.

The solution, then, is to show the extra detail only when it's requested with the -x flag.

This works pretty well, all things considered. The detailed messages are fine, but they could be better—but that's probably always going to be true. It's a start, anyway.

That's very likely true. The context I was talking about probably rounds to "companies with <100 employees", or perhaps at order of magnitude larger at most. I'd imagine that it's quite different in organizations bigger than that. (Not that it's _quite_ accurate to round attitude off to size, but it's probably close enough.)

> The question suggests that you can somehow give yourself a new title which usually isn't true for people who work for someone else.

> In some places to get a senior developer title, you just need to ask. Your manager then tells HR to change one cell in a spreadsheet and congrats - you're a senior software engineer.

That's the "somehow". There is a very strong sense in which whole "asking your manager" thing is a mere formality—it's very unlikely to be declined if the title you're asking for is remotely appropriate (and, to be honest, often even if it isn't.) Your manager is going to be very happy that he or she has a way of keeping you happy and rewarding you for your work _without_ it coming out of their budget (the way a raise or a bonus would.)

So (at least in companies of a certain size, where this is more or less the level of formality attached to job titles), a title _is_ something you can decide to give yourself—yes, you'll want to run it by your manager to get them to ratify it for you, but that doesn't take much. Once you've decided that you want to be called by the new title, the rest is just paperwork to get it formalized.

Absolutely yes. My SaaS startup uses it, and it's really great.

I strongly disagree with the "innovation tokens" argument, at least as applied here. For one thing, while Elixir and Phoenix can certainly be considered "innovative" in the sense that they're better than more common alternatives, they really aren't "innovative" in the sense people sometimes try to scare you with—it's not all that different, on a fundamental level, than those alternatives. It feels very similar to Rails or Django—different in some ways, sure, but not at all alien.

But on a more fundamental level—all being well, this startup is something you're going to be doing for at least the next two or three years, and quite likely more. By far the most important factor in making technology decisions is going to be to use technologies that don't make you give up in frustration. Building a startup is a long hard journey, and yes, there will be many time along the way when you'll be tempted to throw in towel and give up.

If you're working day in and day out in a codebase, framework, language, or idiom that you don't enjoy, feeling that every day is a grind, then regardless of anything else you're chances of getting very far are less then they'd be otherwise.

So you're number one consideration when picking a language or a framework should be something that is a joy for you to use.

Of course, that's not to say productivity with he language (etc) is not important. Of course it's important! It's probably the most important factor that goes into that feeling of joy. That's why so many people love Rails… and that's also why so many people love Phoenix.

So go with it. Forcing yourself to use something that will be a slog for you to use is a fatal mistake for your startup—so go with what makes you feel comfortable and productive. If that's Phoenix, go for it!

My startup has been going for more than a year now, and in retrospect writing it in Elixir with Phoenix was absolutely the correct decision. I can say a lot of good things about it: it's comfortable, powerful, productive, efficient, and so forth. But most importantly, because of all these things, I'm not pulling my hair out. Yes, doing a startup is hard. But at the very least we can avoid making things worse by deciding that the things that are under our control (such as the framework and language to use) won't be adding to those headaches.

Maybe there are other languages and frameworks that are even better. Maybe that's true, although I do think that Phoenix is at the top of the list at the moment. Some people are already comfortable with Rails or the like, and prefer to stay with it. Sure, if that's the position that you're in, that may be the correct choice for you.

But as a general rule, the principle shouldn't be "avoid innovation", it should be to avoid getting stuck in a tech stack which will feel like a grind to work on a year from now.

Proving Too Much: https://archive.md/M1XHf

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.

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...).

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".

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.

You can add `infixl` or `infixr` to that:

    let x = x in do case if let infixr 7 `x`; x = x in True then False else False of _ -> return False

And with the RecursiveDo extension, you can throw `mdo` in there:

    let x = x in mdo do case if let infixr 7 `x`; x = x in True then False else False of _ -> return False

That brings us to `in mdo do case if let infixr` as the longest string of consecutive (distinct) keywords that I can come up with in Haskell.

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".

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:

    type family AllowedToWield (c :: Class) (w :: Weapon) :: Bool where
      AllowedToWield 'Wizard 'Sword = 'False
      AllowedToWield 'Wizard 'Dagger = 'True
      AllowedToWield 'Wizard 'Staff = 'True
      AllowedToWield 'Warrior 'Sword = 'True
      AllowedToWield 'Wizard 'Dagger = 'True
      AllowedToWield 'Wizard 'Staff = 'False

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.

Neomake can do that too: https://github.com/neomake/neomake#setup

With profiles, each profile has it's own history, bookmarks, browser settings, and so forth. In effect, it's a separate instance of Firefox.

Sometimes that's what you want, and profiles certainly aren't going anywhere. But the idea behind Containers is just that you can be logged in to separate accounts simultaneously in multiple containers.

In practice, that means a better and more convenient UI. Containers work on a per-tab basis, so you can have multiple tabs logged in to the same account right next to each other, instead of in different Firefox processes. Plus, you can right click on a link and select "Open in New Container Tab".

So while Containers are more than a UI on top of Profiles, it practice one of the main advantages is the convenience of the UI.

Do note that the robots described in this article only drive autonomously, and when armed, need a human to (remotely) fire the weapons.

If the robot shot autonomously, you'd have a point about mercy. But the way it is described here, it's exactly the same mercy-wise as if the soldier manning the weapons was riding along in the vehicle.