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.
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.
I'm sure he'd have planned or thought about this before hand.
Steve's famous "computers are a bicycle for the mind" was refined over a long period of time and countless interviews. We only hear about the one time where he perfected it, where it made an impression. Many other instances are on YouTube, in one you can see him trying out different alternative lines.
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.
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.
> 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.
> 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.)
That's interesting, I really didn't think that it's that common. In many companies this ranges from very difficult to completely impossible and certainly isn't just a formality. I guess that we have just been exposed to very different types of company/management.
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.)
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.
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.
