smoochy

Okay, but... what difference does it make? Apart from not having to install it manually? Am I missing something?

Can someone please explain: I've been using WireGuard via `wg-quick` command in FreeBSD for quite a while now. What does this commit do?

I've been to all continents except maybe Australia. Only North America has the weird white light for pedestrians and a red palm (which also blinks, which is very counter-intuitive). I can assure, most countries of the world use red and green icons of man standing/walking for pedestrians.

Not sure, reads well on mine. Which phone are you using?

Perhaps you meant "generous". Yes, indeed. Although "generation" contribution is, I'm guessing, might be a noble thing to do as well.

I had written two implementations of the same program in both Ruby in Crystal that need parallel (not threads!) jobs to be run. It did some more or less heavy computation on large data sets. Almost no difference in terms time execution. Crystal is nice, but if Ruby is the same, what's the point? Only thing I don't like about Ruby now is how they implemented types (in separate files... no, thank you).

But generally speaking, after 14 years of Ruby... and also trying many more languages - I do know what I want. It's not speed. It's not memory safety. It's not paradigms. It's not static or dynamic typing. It's not the packages and the community. Nope.

I want easy code navigation. I only currently know of one language, that hasn't even been fully released yet, that achieves this task to a degree. But even then, it's only 30% there.

I use Ergodox too, but this gallery of yours, this is sick man. I need to check this out, every one of them I'm not aware of.

Synesthesia isn't about associating numbers, musical notes or other things with COLORS. It's associating any one collection of things of the the same type (say, days of the week) with pretty much any random set of objects, forms, colors, shapes or whatnot. I read the article and then all the comments here and it appears to me that most people are collectively blind to the fact that it isn't just about colors [1][2].

UPDATE. A thought I'd just had: it appears very intuitive that most people do have synesthesia, they're just not consciously aware of it, or, sometimes, don't even know what to call it.

[1] Wikipedia article: https://en.wikipedia.org/wiki/Synesthesia

[2] Cynically explained by Rustin Cohle: https://www.youtube.com/watch?v=FaYiq9x7odE

Can someone articulate the differences from zfs? Apart from the fact that, Google's file system seems to be working better with large files and allow simultaneous writing (or, rather, appending) without blinking an eye. But that'd be useful for, maybe very large tech companies.

It's beautiful poem for any age. It's a gem, which I discovered only recently when I re-watched the film. A gem hidden right there, in plain sight.

My only ally in this life has always been serendipity. That's why I replied to this post. It's a simple post. Ice cream is simple. Kindergartens are simple. On their surface, of course. You ever watched "Kindergarten Cop"? Try and watch it and remember that scene where Arnold reads a poem. Find that poem. Read it whole.

Sometimes things that appear shallow bring about the deepest truths: if you take effort not to ignore what you're looking at, what you're hearing at the moment, if try not to ignore all your other senses. Suspension of disbelief is crucial, ESPECIALLY if you want to write something - even non-fiction. Or else, how do you expect your readers to do the same and believe your words or least consider them, if even you yourself cannot do that little trick?

I may. I wrote a book once. Hard work. I think you may need an editor, rather than a co-author. Someone who'd proofread and rearrange every sentence of every paragraph of every page of every chapter. And do it 10 or more times for each of those sentences, paragraphs, pages and chapters - before it can be published even as beta. Furthermore, as we all know, senior engineers disagree vastly on so many tiny little things: preferences, practices, routines, while simultaneously agreeing on some deeper inherent truths. But keeping that in mind, co-authoring may work out kinda like Rustin Cohle and Marty Hart worked out in True Detective - in the end. Question is, what kind of journey are you up for. And where am I.

Drop me a line, the email is on my website orion3.space

People downvoted you, but I completely agree. It looks like this is NOT satire, but I hope you turn out to be right. Maybe someone has some sense of humor and enough time on their hands left to pull such stunt.

It is true though. These were exactly my thoughts when I was reading the page. Well, not exactly, because I instead said "Duh".

Let me settle this debate: as I originally stated, the young developer was not stupid at all. She knew about HTML and forms and everything. She just didn't know how to work with it and, more importantly, she didn't want to get into that at the time, explaining that she didn't "want the site to look ugly" and that it was "a project for the portfolio" (implying that she needed to demonstrate her React skills).

So that's what's really troubled me. The companies responsible for producing this piece of garbage are actually getting into the heads of the younger generation, rendering them helpless without said garbage. I repeat, this is indeed garbage, especially React: in early 2000s we used to laugh at people mixing JavaScript and HTML, but some of them, apparently, decided it was their time to strike back.

The more important issue is, of course, that we have a generation of young people working with these "tools" which isolate them from learning things that actually matter. These levels of abstraction DO NOT add any value. These are "cargo cults" of abstractions, which without their authors knowledge (because those who invented them weren't very smart anyway) serve the purpose of keeping potentially talented and intelligent people ignorant and average. This is probably good news for somebody out there, but certainly not for us as a society.

I was reading your comment and thought of Jonathan Blow's talk. Without even clicking the link, let me guess, that's from Moscow's 2019 conference?

EDIT: yes, it is. He has a very important point there. I recently went on Twitch to see what young devs where coding. One (rather smart, I must say) young lady was creating a simple sign in/sign up page, but there's a twist: with React. Upon me asking, why wouldn't she just code it in plain HTML, she responded with a question: "but how would it connect to the API?". So there you go, ladies and gentlemen. I don't really know what to do about it, but I don't believe we're a bunch of old men yelling at a cloud (quite literally - AT A CLOUD), especially that I don't think we're that old.

I wrote about it here, search for "NixOS" on the page https://orion3.space/articles/2weeks.html

I wholeheartedly agree. My initial motivation for building `dock` was actually looking at all the vulnerabilities in different packages for various package managers and thinking "I would not like that on my system". Then I decided it would generally be a good idea to isolate other stuff. Like you can actually run your browser from a container, without it having access to your filesystem and, possibly, other information your OS provides. Dock for me wasn't about NOT setting up the environment, because I WAS actually setting it up for every single container I'm using. But it was about not having to set it up again again, let alone managing conflicts.

Yeah, ok. I'll be setting up a Github repo soon. I guess that's how we roll these days. Github will be learning more about how to program Bash then.

Could you please email me the git patch? Or put it on Github/Gitlab yourself and send me the link.

(I think I do make it a bit complex for people to contribute, but I don't have a lot of time to spare).

I wasn't paying much attention to all sorts of safety issues, like potential RCEs, because this was initially intended for local development, not production use. But do let me know if you see how someone would be able to exploit those scripts without `dock` user knowing about it.

Also, thank you for trying it out and reporting it works even on Windows, pleasantly surprised.

I think you're not seeing the actual point. The review isn't solving the issue. If you have two branches with alternating environments and you switch back and forth between them, how do you suppose your Dockerfile would handle it? What if that change isn't as simple as switching the Ruby version, but "compile and install some software" or some obscure config changes? I mean, it would be breaking all of the time, you'd end up having two containers anyway and you'd be scratching your head as to how to switch between them easily.

So, if you would, say, spend 10 minutes to install `dock` I guarantee you, you'd love how uncomplicated it makes everyday container usage. It doesn't get much simpler than a single four-letter command with no arguments.

Thank you, both issues fixed. At least that's how you know someone tried it. Issue #1 was extra \ without the newline character that was supposed to follow and Issue #2 was me forgetting to push the branch after I recently migrated the site.

AFAIK, there's a port of FreeBSD's bhyve to MacOSX called xhyve. You might want to check it out.

I've never used Docker in production, there was no need for containers. We did use heavier VM, but kept the environment and configuration such that it wouldn't need some kind of special handling. That is to say, once a team member cloned the project(s), set up the environment on their machine and successfully made the project run, there wouldn't be any constant tweaking with the environment afterwards.

Even you're running a lot of micro-services, your goal is NOT to make it so that they are impossible to run without hours and hours of environment setup. In fact, even though they are different micro-services, you'd probably want to make their environment similar or the same where it's possible.

The purpose of containers for me personally is to isolate potential crap coming my way from various package managers, such as nodejs and, if I were to use them in production, to minimize a potential security breach impact.

But the idea that it's the same environment on the developer's machine and that we should deploy containers and not code, is absurd to me.

Fun story. I gave Nix a try - my standard 2 weeks - and realized it's not solving my problems, while creating a set of different ones. Ironically, `dock` was conceived while I was experimenting with Nix. But Nix... and Docker, in part... They are manifestations of this need for certainty we humans have, it doesn't lead us to good places :)

That's the point. This tool is not for the teams. It's for your personal development needs. I often find myself working on multiple projects, which require roughly the same environments. Say, I may need a container with PHP for multiple projects, but each would differ slightly in some way. Maybe some configuration file, maybe something else. I would just `cd` to the project's dir, type `dock php8` and it would create a container based on the "dock/php8:stable" image. Then I'd install whatever else I need. I wouldn't need to bother editing a Dockerfile. I would get a nice shell immediately as I type the command. And I wouldn't need to remember that I'm running a container (even if it was stopped), because if I go the same directory and type `dock` (no arguments), it would automatically start/connect to the right container.

I've tried using Dockerfiles with teams. Over time it gets absolutely ugly, because you have to keep track of yet another configuration file collectively. It's all fun and games until someone creates a branch with an updated Dockerfile, you check it out, it alters your container and then you go back to master only to find out nothing works. That's just one example of madness.

We cannot rely on containers as a collective development tool. They're not, it was a dumb idea in the first place. Dockerfiles effectively make system configuration and setup a part of your vcs repo. And that is wrong. We might as well check in the root filesystem into the repo altogether then.

Once the "patching" system is finished, it will work on any system, regardless. See my comment here: https://news.ycombinator.com/item?id=31625835