If you actually want to use vxlan ids to isolate l2 domains, like if you want multiple hypervisors separated by public networks to run groups of VMs on distinct l2 domains, then vxlan over WG seems like the way to go.
620 karma · joined December 24, 2018
There's nothing wrong with this. Being able to explain your thinking in detail to someone that doesn't necessarily understand the problem is a pretty good exercise to make sure you yourself fully understand the problem _and your thinking._ Of course, this can't turn in to a lecture on basic things people should know or have looked up before commenting.
Architecture / Design review happens post proof of concept but still before any significant development work and major action items are blockers to beginning development. Further discussion about designs not chosen can happen here, especially when a flaw is uncovered that would be addressed by one of those not chosen.
I may have missed it or didn't understand it when I heard it explained. What underpins the notion that when a particle transitions from a superposed to defined state, the other basis states continue to exist? If they have to continue to exist, then okay many worlds, but why do we think (or know?) they must continue to exist?
Quantum superposition is real. There's no doubt about that.
I'd say there's really no "linux roles" out there. Entry level or not. Everyone collectively decided "devops" was a big bright beautiful tomorrow and made devs learn release management and made ops people get lost (or become the developer they never wanted to be). Everyone shifted their focus towards "as code" solutions because the SRE book said nobody should log in to servers or something. So we hire people that know the abstractions instead and assume nobody really needs to go deeper than that.
It sucks, but learning the abstractions is how you're gonna have to get started. If you're already a linux nerd then you may benefit from understanding what the abstraction is doing under the hood.
If I was starting out right now, I'd go work through Kelsey Hightower's 'Kubernetes The Hard Way' and build functional kubernetes clusters from scratch on a couple of the cloud providers. Do not copy&paste anything from the blog. Every line, every command, by hand. Type out those CSRs and manifests! Recognize what each component you're setting up is and what it's used for. Like "what is the CCM and what's it responsible for?" Or "What's going on with every step of the kubelet bootstrapping process? What controllers are involved and what are they doing?" Read EVERYTHING under kubernetes.io/docs. Understand the relationships between all the primitives.
If you already have some linux, networking, and containers knowledge to build on top of, I think you could work through all of that in less than 4 weeks and have a better understanding of kubernetes than 80%+ of engineers at any level and crush a kubernetes focused interview.
In my experience it's the network of people you've worked with that know how beneficial you are and want to work with you again (this is key) that will keep you in demand regardless of the market conditions.
- Try to find a way to not go to the meeting. Anything you say, especially the most insignificant part, will be used against _someone_ in an argument that doesn't make any sense. You're going to feel the need to correct their misunderstanding and misuse of what you said. You might even try to re-focus the discussion back to the important thing you were _trying_ to say. It only goes down hill from there. You're better off interfacing with a group of C-level people through documents.
- 1:1 meetings can work. Make sure you can back up everything you say with data.
- You're a developer, you can't estimate time and effort for shit. If asked, say you'll get with your manager or the PjM or w/e to get a date.
- Find out from the person that asked you to join what you should be prepared to speak to.
- If there's an agenda or documents that will be discussed, read them before the meeting. Doesn't matter if they plan to read it during the meeting.
- No hemming and hawing. If you don't understand what you're being asked, ask for clarification. If you don't have an answer you're confident in, say so. If they insist, prefix your crisp and concise answer with your level of confidence. "In my experience.." "From what I've read.." etc.
I can tell you I do not enjoy thinking. I hate it. It is a compulsion that I cannot avoid. I know that it makes most interactions in my life more difficult. I know it's a source of unhappiness. I cannot stop thinking.
I want to do. Not think. I fail to do. I think about failure.
We train ourselves on content. We give more weight to some content than others. While listening to someone speak, we can often predict their next words.
What is thinking without language? Without language are we just bags of meat reacting to instincts and emotions? Are instincts and emotions what's missing for AGI?
Or they could have not mentioned kafka at all and just demonstrated their pub/sub implementation with PG. They could have not tried to make it about the buzzword resume driven engineering people vs. common sense folks such as himself.
If you don't need what kafka offers, don't use it. But don't pretend you're on to something with your custom 5k msg/s PG setup.
I really want windows to be able to span columns. So if I have 1 column with two windows and focus on the bottom window then create a new window/column to the right, I want that new window to be on the bottom half of column 2. I want the window from the top of column 1 to stretch across columns 1 and 2. If I again create another window/column to the right, that top left window should stretch across columns 1-3. So I should have one very wide window across the top of the screen and 3 windows across the bottom.
I've started playing with this idea in the hyprland hyprscrolling plugin but I'm kind of an idiot and don't have much free time these days.
I also don't have spotify. I used to have spotify but it started playing spanish language commercials for no apparent reason and their support wouldn't do anything about it other than inform me that if I paid for an account there would be no commercials. So I started paying for apple music.
> System design requires competence with a lot of different tools: app servers, proxies, databases, caches, queues, and so on.
Yes! This is where I see so many systems go wrong. Complex software engineering paving over a lack of understanding of the underlying components.
> As they gain familiarity with these tools, junior engineers naturally want to use them.
Hell yea! Understanding how kafka works so you don't build some crazy queue semantics on it. Understanding the difference between headless and clusterIP services in kubernetes so you don't have to build a software solution to the etcd problems you're having.
> However, as with many skills, real mastery often involves learning when to do less, not more. The fight between an ambitious novice and an old master is a well-worn cliche in martial arts movies
Wait what? Surely you mean doing more by writing less code. Are you now saying that learning and using these well tested, well maintained, and well understood components is amateurish?
I don't know of any reason that wouldn't work, but I haven't tried it so I'm not certain it would.
LCDs were a thing (tho they were not great back then) and Plasma was the new hotness ( literally, they required external cooling units). The market for a thin, flat "CRT" like display was in extreme hot or cold environments, aviation, marine, stuff like that.
I heard they actually built one, but I never saw it. I was gone as soon as my paycheck bounced. This place was actual crazy. All sorts of bizarre shenanigans.