cytzol

Not the parent, but I really like Nomad + Consul + Fabio (or Traefik) too. I tried learning Kubernetes but there was so much to take in all at once; I tried learning the HashiStack and I could try it out one product at a time.

Kubernetes is the Git of container orchestration. It doesn't matter if any other products are better when k8s has, like, 99% of the mindshare!

Yes, you can get smaller binaries using compile-to-native languages. But speaking as someone who had to install the JVM and our application on clients' computers, this is way better! You don't need to be the best to be good.

GUI user here. Genuine question: when would you need to pipe stuff through grep? I get it would be a rare situation, but I can't think of one.

Yeah, it's great news for me too. Earlier this year I tried setting up VPNs so my droplets could speak to each other in isolation. Knowing that I don't have to worry about that will be a load off my mind.

neverssl.com has saved me several times.

> Really? Even if you haven't selected the line?

Yeah

I'm far more familiar with Vagrant than Docker, so there may be Docker solutions for these problems. But I use Vagrant to:

- Test my software on a "fresh" Linux installation, to ensure it doesn't have any hidden dependencies

- Test my software with different filesystem layouts and (soon) different filesystems, without having to pollute my own filesystem with hundreds of test files

- Automatically install a set of global commands in the VM (such as "b" to do a complete build) and display help text as soon as a user runs "vagrant ssh", so a new developer can quickly get up to speed

It's been pretty good!

I've been using Vagrant + Virtualbox and have been happy with it. Is Vagrant + VMWare really that much of a step up in performance? Could you explain which features have been helpful? Thanks.

Oh, right. Yeah, that would be nice, but my company doesn't use languages with that feature, and we can't re-write our software, so we're stuck with Option types.

>> Grandparent: "I think you should just let your code crash."

> Parent: "I think that is a bad idea."

It seems pretty clear that we're talking about crashing here.

> But you will also loose "App Control".

For fuck's sake... Thanks for the "upgrade", Apple.

> It must be nice to work in an environment where nobody cares about results.

Not crashing when there's a bug is not "success", it's just "zero visible errors"!

If your workplace really cares about results, they'll understand how futile it is to keep executing even though there's a bug. You start second-guessing your own program, which makes the code quality worse as the assumptions it makes are no longer clear; you won't be alerted to problems, as the program won't be aware of any; there'll be no guarantee that your code isn't just working "by accident" at the moment.

I'd love it if the code I deal with just crashed instead of pretending everything's alright, because it makes errors far harder to diagnose.

> Ask me about using a Java library that could return an option type, which could be null, so you have to check for both the None return value AS WELL AS null.

No, you don't -- because those are two different kinds of null!

If your library's function returns Optional.empty(), then it's because it successfully returned no value. If it returns null, though, then the library has a bug and you should crash instead of trying to continue in a known invalid state.

Without the Optional type signature, the function would return null for both of these, and your program will appear to work even though it's just suffered a bug.

I've been wanting to do this for ages, but I can only find the volume slider! Could you tell me how to put Volume Up and Down buttons on there please?

> There’s lots of Tim wresting highs to do with the watch.

"Interesting things"?

Ah, I'm with you now. And yeah, I do agree that a line has to be drawn somewhere. exa would probably fail if used with a screen reader, or heck, it doesn't even work properly under Windows right now. That's a huge market I'm ignoring!

What I've seen people doing is saying that there's no line at all: every feature needs to have its cost justified, every type of user scrutinised to make sure they're not dragging the product down. This is expected behaivour for startups (launch to a limited market first) and big companies (where you need to justify every cost) so I'm not surprised to have encountered it here.

For colourblindness in particular, though, I still think there has to be a way for the default colour scheme to be colourblind-friendly without the experience for everyone else suffering as a result.

I do not like this attitude one bit. exa isn't here to make money, it's here to list files; if somebody can't use the software, then that's one less member of the community and one less person who can offer suggestions, rather than a resource who wouldn't give me a return on my investment.

If you're colourblind and two different parts of the interface look too similar to you, then please, raise a bug.

Yo. What's it display? Feel free to raise a bug if something doesn't look right. I know it's not the fastest-moving open-source project, but I'll still read everything that people submit.

Cheers. Yeah, most of the comments on the colours have mentioned the permissions column in particular!

I've seen k before, it's pretty neat.

You can't grey out the columns in exa until I land configurable colours, which I hope to get done relatively soonish. But you can use the --colour-scale (or --color-scale) option to colour file sizes based on how big they are. The person who submitted the feature request (https://github.com/ogham/exa/issues/65) used k as a direct example.

Sorry the colours aren't working out. One of the feature requests in exa's pipeline is the ability to customise the colours, so you could make everything use bold colours if it's too dark, or make more things the same colour if it's too garish. Would something like this make it usable?

Speaking about the point in general, though, I think that terminal programs have been in a chicken-and-egg situation for the last decade or so with ANSI colours. Because colours only get used sparingly, not all terminals have good-looking colour schemes by default, which means they often look ugly, which means they only get used sparingly. There shouldn't be any reason why a terminal program should ship with unreadable colours by default (I have been killed in NetHack before because the default 'blue' colour in PuTTY was so dark, I could barely see it), and terminal programs that output colour should be smart about it (disable colours by default when not to a terminal, to avoid problems with grep like the one you cite).

I'm disgusted, yet intrigued.

Well it's too late to change now! It's one-handed, even on Dvorak, which is a bit annoying.

I don't think it's too much of an ask for people to define their own aliases for it, though. The overlap between people who install custom command-line tools and people who know how to edit their shell config can't be small.

Thanks for the kind words, everybody.

exa was my first Rust project and it just grew and grew.

> That said, the binary isn't self-contained (I know, I know)

It wouldn't be right if something didn't go badly wrong at the worst possible moment!

You're right -- I missed it out! Could have sworn I put one in one of the screenshots, too...

In any case, I've been working on a new site for exa, with much better documentation and actual explanations for what the features are, and that has one in it. So you'll have to wait a bit longer I'm afraid. (I could link a screenshot here if you'd like one)

Oh, I completely missed that word. My bad.

Thanks! Configurable colours are something I'd like to get done, too. About half the work has been done to achieve this -- none of the colours are hard-coded, they're all looked up from a big Colours value that gets passed around internally. This value just needs an interface so it's configurable by the user. I've been meaning to open it up to the community instead of just defining an ad-hoc EXA_COLO[U]RS environment variable, but y'know, time.

You hit the nail on the head!

Like I've said in these comments, I'm constantly surprised by which settings people change and which ones they don't, so differing opinions on exa's defaults is nothing new. exa shares my opinion of wanting to see thousand separators and byte suffixes by default; ls, on the other hand, has no opinion because with file sizes that small, it didn't really have to choose what the output should be like.

People have said that in scripts you'd want to just output the file size in bytes, and they're right, otherwise the numbers won't sort correctly. If you're writing a script, though, you're going to be taking more care than if you were just wanted to list some files. I've lost count of the number of times I've listed a directory, given up trying to count the digits of the file sizes, then re-ran the command with `ls -h`, but I've never written a script without thinking about what the output should be like.