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)

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

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.

Comments URL: https://news.ycombinator.com/item?id=29291172

Points: 85

# Comments: 95

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.

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.

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

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.

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.

Comments URL: https://news.ycombinator.com/item?id=21681395

Points: 238

# Comments: 39

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

Comments URL: https://news.ycombinator.com/item?id=20212730

Points: 2

# Comments: 0

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

That doesn't mean it will be any easier (or harder), but it does mean that it is less of a "moonshot".