It depends on how you were running before -- if you had the wireguard-kmod package, then yes, the only difference is that you don't have to install it manually. If you only had the wireguard-go pkg before, then see the other responses where you'll now be using the kernel implementation instead of userspace.
edit to note: we can't really provide wg-quick in base at the moment (uses bash-isms), so that still ends up needing installed manually if wg(8) isn't sufficient for your needs.
If I recall correctly, we went through this on Linux in the past. I believe the first wireguard implementations were userspace while the work was being done to get it in the kernel.
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.
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.
> 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).
You answered your own question ><
> I want easy code navigation.
Static types makes this a much, much more solvable problem. But I'm curious about what you mean here, because modern code navigation tools are pretty good - even for Ruby - but perhaps I am not fully understanding what it is that you are after.
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.
> 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.
The Wikipedia article is vague, but I've always thought of synesthesia as meaning that a stimulus in one "category" provokes a response in another "category"—Wikipedia and your post seem to say the same thing, but with different, and more technical, terminology in place of "category". More to the point, there seems to be some implication that this is a response that "shouldn't" happen; that there is an appropriate response to the stimulus, and that the actual response isn't the appropriate one.
But it seems that, if, as you suppose, most people have synesthesia, then the problem is one of definitions. If most people have an inappropriate response, then doesn't that mean that the definition of 'appropriate' is wrong—it's meaningless to say that everyone is abnormal!—so that mass-scale synesthesia must, if it exists, indicate nothing unusual per se about synesthetes, but rather a poor mapping on the part of diagnosticians?
I think almost everyone has associations between things of different "categories" (you can almost smell the grass if you picture yourself in a field). As a synesthete, I have both kinds of associations (synesthetic, and non-), and many lie in the spectrum between.
The strongly synesthetic associations are 1) always-on*, 2) automatic and immediate, even for novel stimuli**, and 3) consistent over time***
* You can turn your focus away from them, like focusing on a person's voice in a noisy room, but you're still aware of the noise.
** You won't experience the smell of grass looking at a photo of a field, if you've never been to a field before. But many synesthetic associations occur immediately even for new stimuli, especially if it's a simple input like sound. If it's a complex concept like someone's personality or an algorithm, they are initially in flux and solidify as understanding of the concept improves.
*** They can change very slowly over time (years)
The above is more of a personal definition from my experience, and not a clinically accepted one.
This is correct, I see visuals when I hear sounds. The textures and shapes correspond to the type of sound. For instance, a clean guitar has a different texture than a distorted guitar. Same for people's voices.
Came here to say that I experience similar, and my career is centred around audio. When people talk about "brighter" and "darker" sounds, that's very much a tangible concept to me and not some abstract thing. Different sounds have different colours, and my DAW templates are always based around this. Any gear that uses LEDs that can't be reassigned is a nightmare for me as it's visually overwhelming.
Funnily enough, I do a fair bit of scoring picture and games, and I find that the scene informs what kind of music I'll make. It's not painting-by-numbers though, but it's like sharing synaesthesia in a tangible form.
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.
GFS/colossus is designed to offer similar level of features (well in terms of performance and namespace, not snapshots) but over many machines.
ZFS doesn't have to worry too much about latency, or another machine writing to the block that it wants to update. As soon as you break free from one machine, you have to think about how you deal with: where data lives ( is the data stored seperate from the metadata?) how a client signals who has a write lock, permissions (ie user authentication, nfs basically just uses UserIds, which can be faked, unless you are running kerberos/NFSv4) data affinity (pull data from another data center is expensive, do we sync, cache or clone? how do we resolve write clashes?)
All of those questions have an impact on speed, scalability, reliability and durability. You need to choose your designs carefully to get a filesystem that does what you want it to
One of the most important differences is that Colossus and GFS are user-space filesystems for the client. You're just making RPCs to a service. There is no kernel filesystem. Upgrading the client and the server is just software upgrade, no kernel changes. And the operations were intentionally restricted- for example, instead of the debacle that is locking in NFS, locking is part of a different (and even more fundamental) tech at Google (chubby, which is NOT a filesystem, or so they say).
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
