Yes. 15-20 years ago when I was still working on network-adjacent stuff I witnessed the shift to the devops movement.
To be clear, the fact that devops don't plan for AWS failures isn't an indication that they lack the sysadmin gene. Sysadmins will tell you very similar "X can never go down" or "not worth having a backup for service Y".
But deep down devops are developers who just want to get their thing running, so they'll google/serveroverflow their way into production without any desire to learn the intricacies of the underlying system. So when something breaks, they're SOL.
"Thankfully" nowadays containers and application hosting abstracts a lot of it back away. So today I'd be willing to say that devops are sufficient for small to medium companies (and dare I say more efficient?).
> But deep down devops are developers who just want to get their thing running, so they'll google/serveroverflow their way into production without any desire to learn the intricacies of the underlying system. So when something breaks, they're SOL.
Depends on the devops team. I have worked with so many devops engineers who came from network engineering, sysadmin, or SecOps backgrounds. They all bring a different perspective and set of priorities.
That's not very surprising. At this point you could say that your microwave has a better uptime. The complexity comparison to all the Amazon cloud services and infrastructure would be roughly the same.
All my banking apps works fine under lineage. The only app that does not work is McDonald. I have not investigated very far, maybe it is possible to make it work.
I feel like I am not asking THAT MUCH from my neovim setup, but it is so complicated. My collection of vim config is about 1000 lines, that's insane, but when I try to trim it, everything seems required.
My requirements:
- language support (syntax, formatting)
- lsp (I want the goto definition)
- file browser
- quick jump (fzf...)
- a little bit of eye candy, nice fonts and a few icons to make things clear
- auto reload if file changed externally
- splits I can manage with the keyboard
- persistent undo
- in terminal or with excellent SSH remote editing
I would love to have an editor with better defaults. I don't mind learning something good and robust if it will serve me for years.
My emacs configuration is around 500+ larger, but that's mostly because emacs is a whole ecosystem. My `.vimrc` is 244 lines and I think the lsp settings is around 100 of that. The rest is mostly mapping and a few plugins (vinegar, surround, fzf,...).
My configuration[0] doesn't quite meet all of your requirements, but you might be able to get some ideas from it. If you delete my hacky and very opinionated color theme configuration, it's 418 lines.
- I use Neovim in the terminal, so that's where I configure the font (Hack Nerd Font Mono) [1], which I install via homebrew on macOS[2].
- LSP: Can't recommend mason.nvim and mason-lspconfig enough. Install LSP servers with mason.nvim, and then mason-lspconfig handles automatically configuring and enabling whatever you've installed.
- I'm using mini.icons[3]
- For the file browser, I highly recommend Oil.nvim[4], which I discovered from this video by TJ DeVries[5].
- I was using fzf-lua, but switched back to Telescope because it was a better fit for me personally (I missed C-k to automatically append a file glob to live_grep. I missed being able to toggle the previewer. I missed being able to hit Esc and move around the picker input box with Vim motions)
Might be misunderstanding "splits I can manage with the keyboard", but (Neo)vim is pretty configurable here! I actually just use the default keybindings of e.g.
- `C-w` then HJKL to move
- `C-w C-v` to open a side-by-side (vertical) split
- `C-w C-q` to close the current split
- `C-w C-o` to close other splits (make current split the only one)
- `[NUMBER] C-w C-w` to jump to the [NUMBER]th split.
- `C-w o` to jump back to the last split you were at
For me the only thing that really matters, and globally sucks with WiFi is roaming.
My house is old and has stones walls up to 120cm, including the inner walls, so I have to have access points is nearly all rooms.
I never had a true seamless roaming experience. Today, I have TP-Link Omada and it works better than previous solutions, but it is still not as good as DECT phones for examples.
For example if I watch a twitch stream in my room and go to the kitchen grab something with my tablet or my phone, I have a freeze about 30% of the times, but not very long. Before I sometime had to turn the wifi off and on on my device for it to roam.
I followed all Omada and general WiFi best practice I could find about frequency, overlap... But it is still not fully seamless yes.
DECT phones run on the 1.9 GHz spectrum which doesn't get absorbed by water like 2.4 GHz, and will penetrate through many other materials far better than higher frequencies.
Most people place wifi repeaters incorrectly, or invest in crappy repeater / mesh devices that do not multiple radios. A Wifi repeater or mesh device with a single radio by definition cuts your throughput in half for every hop.
I run an ISP. Customers always cheap out when it comes to their in home wireless networks while failing to understand the consequences of their choices (even when carefully explained to them).
Eh, multiple APs and roaming being awful isn't just a matter of shitty placement and bad wireless backhaul, it's also client side software. I have two APs on opposite ends of my house and my phone tries to hang on to whatever AP its connected to far longer than it should when moving around the house. My APs are placed correctly, and support 802.11r, yet my phone and most other devices don't try to roam until far, far past the point they should have switched to the other AP.
The design of roaming being largely client initiated means roaming doesn't really work how people intuitively think it should, because at least every device I've ever seen seems to be programmed to aggressively cling to a single AP.
You may need a third access point in the middle of the house then which would enable you to further reduce tx power on the access points while maintaining good reception of client transmissions by the APs, as clients won't roam unless the other access point is of a sufficiently better signal strength. With only 2 access points the signal level in the middle of the house may be too low for either AP to maintain good reception. As always it depends on the materials in the walls, the placement of large metal obstacles like ductwork or appliances, the antenna orientation on the access points.... You would have to measure the signal levels and build up a heat map to figure that out.
Of course with 3 APs instead of 2 the best layout is different.
People are almost always better off more cheap access points than fewer expensive access points, but that's not how most regular folk reason.
Have you tried turning down the tx power on your APs? It will help your devices decide to roam, and it may not actually reduce your effective range, because often times effective range is limited by tx power on the client more than the AP.
I have, doesn't really help very much unfortunately. Setting an RSSI threshold on the AP can also help devices roam, but its hard to set it at a level that works for all devices (since different devices have different sensitivities so an RSSI threshold that works well for my phone might cause some other device to constantly get dropped).
I assume you have hardwired all the APs, otherwise that would be the first step. Make sure they're on different channels, and have narrow MHz bands (20Mhz for 2.4GHz, 40MHz for 5GHz) selected.
Only use 1,6,11 for 2.4GHz and don't use the DFS channels on 5GHz as they will regularly hang everything.
Afterwards you can try reducing the 5GHz transmission power so there is no/less overlap in the far rooms.
Unfortunately you probably need the 2.4GHz (at least I do) but as the range is so much higher it might make sense to deactivate it on some APs to prevent overlaps.
Doing this basically eliminated the issues for me.
XMPP has very nice server implementations, and the protocol is OK regarding complexity.
But the clients are lacking. On linux there is gajim that is "okish" but it lacks calling capacity with mobile clients. On mobile there is conversation and derivatives on android which are "nearly there" and monad on iOS.
Globally, the main lacking features are:
- voice and video calls cross platform
- gif integration, tenor/giphy/imgur...
- fast sync (if you open gajim after being offline for a week, it takes ages to catch up)
I kind of view the lack of gifs as something positive? Like, it forces one to use actual words and think out a response.
Plus, you're not leaking all the tracking associated with those widgets.
However, I understand that people have come to expect having fun experiences in their IM clients, and that usually requires reacting with animated GIFs.
In my book it only got worse. Way worse. Sure, it looks more familiar to those who is used to iMessage/Whatsapp/Telegram, but I bet it would still look quite alienating for that audience. And for those who remember Gajim 1.x, disastrous UX doesn't outweigh introduction of reactions, history syncing and whatnot. Last time I checked it a couple of months ago:
- It was not possible to close group chat without leaving MUC.
- I had to constantly open separate search dialog to write to someone who's already in my roster but is not in the list of active chats.
- Speaking of active chats: what annoys me the most about modern IM clients (and that includes Gajim 2.x) is that list of chats is sorted by the last activity date. I don't even know how Whatsapp/Telegram users live with this, I got so fed up with hovering my mouse/finger over one chat and tapping it only for the whole thing to reorder in the last jiffy and opening something completely different, I just dropped my account from one of those centralized mass-market services altogether. It is that annoying.
- It had lots of smaller warts like nickname autocompletion requiring way more key presses (especially after someone mentions you).
You can buy prepaid SIM cards with cash, and without hassle, in the US as well.
You can do this in many countries, I believe, as well as online through services offered in exchange for crypto.
You didn't define where "here" is for you. Mexico is a better option than the US because the retail price of a SIM card with a number and service is around 50 pesos (maybe lower).
Here (switzerland) lights turn red on purpose to slow down traffic. The idea is that if you see a green light in the distance, you are motivated to speed up to catch it before it turns red. If it is red in the distance, you slow down because you eventually have to stop, and when you are like 20m from it, detectors will see you and turn it green.
My experience as a cyclist contradicts that: many motorists will still (riskily) overtake you just to reach the red light sooner. Some people apparently just can't stand to have anyone driving before them. See also: people passing by you on a multi-lane highway and then promptly slowing down once they have returned to your lane...
I don't understand this. There is a red light. You will have to stop. Why do people still cross a solid line (which will get you a fine if police sees you) to overtake me and then stop directly in front of me? It makes no sense.
It's even worse when they overtake me and stop in front of me at an intersection with two lanes where they could just stay in the fucking lane they used to overtake me.
I swear some driver are doing it on purpose because they hate everyone else on the road.
The faster you get your car to the inductive sensor in the road, the faster the lights change.
And plenty of turning lanes in New Zealand will not trigger the green turning arrow unless a car is waiting. If you don't get onto the sensor before the phase completes for the cross traffic, then you need to wait a full phase of lights before the green arrow is enabled (which can be quite a while, depending on pedestrians and other turning lanes etc).
It depends on time of day and wether cars coming the other direction are waiting to turn.
A few intersections are very cycle unfriendly, because they separate induction sensors for cycles are not installed for all lanes.
Not saying that your explanation is wrong, just saying that in some circumstances, hooning up to the light can reduce wait times for drivers.
The same thing can happen when walking (pressing the pedestrian cross button in time can reduce the waiting time before you can cross), or cycling (sometimes you need to get onto the cycle induction sensor to get the green cycle lights faster).
>My experience as a cyclist contradicts that: many motorists will still (riskily) overtake you just to reach the red light sooner. Some people apparently just can't stand to have anyone driving before them.
???
Seems like the far more plausible reason is that drivers don't want to be held up by a cyclist traveling at 10mph in front of them? Moreover if it's really true that lights only turn from red once a car reached them, then it makes sense to maintain speed (including overtaking any bicycles), because getting to the light faster means it turns to green sooner.
Sibling commenter covered most of what I have to say but the other reason this is wrong is because many bicycles can go 20-30mph, and I'm just going to leapfrog you anyway at the red light you're racing me to wait at.
Other times cars try to kill me to save themselves a few seconds:
1. turning right into a parking lot ahead of me
2. turning right out of the parking lot ahead of me
3. rushing to open their driver's side door right in front of me so they can get out and get to their destination faster
I've had a crash for #1 and #3, so this isn't theoretical. Watch for bicycles.
>Sibling commenter covered most of what I have to say but the other reason this is wrong is because many bicycles can go 20-30mph, and I'm just going to leapfrog you anyway at the red light you're racing me to wait at.
Right, but the whole premise of this thread is that the lights only turn green after a car approaches. If you overtake the bicycle so you can get there 5s faster, then the light will turn green 5s faster. Sure, whether risking an overtake to save 5s might be questionable, but is at least a more understandable reason than "Some people apparently just can't stand to have anyone driving before them", which makes it sound like the driver can't stand being #2.
the original statement was that drivers do it all the time, wether the traffic light might pass green or not.
Many cyclists slow down when they see a traffic light being red with a lane of stopped car in front. Because cyclists understand physics and drivers are generally bad at anticipating events.. Almost universally a driver try a quick pass to brake check the cyclists and stop in front of the cyclist while it would be more efficient for both of them to gently slow down instead of stopping so they still have speed when the light go green.
> Seems like the far more plausible reason is that drivers don't want to be held up by a cyclist traveling at 10mph in front of them?
You sound like one of thos drivers who believe it's OK to put other people at risk to save themselves a couple of seconds.
I see this all the time in my large truck that I'm very good at coasting into red lights. Even when there are already vehicles stopped at the light, people will not only stay on the gas way later than necessary and then brake unnecessarily hard but will also pass me to be sitting one car length further ahead at that light. Often it is done dangerously, without turn signals or proper blind spot checks. I know this because I've also almost been hit repeatedly on my motorcycle by cars doing this.
>You sound like one of thos drivers who believe it's OK to put other people at risk to save themselves a couple of seconds.
See my other comment. My point isn't that it's suddenly okay to overtake because the driver can shave off 5s, just that the cartoonishly evil caricature of the driver's reasoning that OP dreamed up isn't accurate. Unfortunately, judging by the downvotes it seems like people are interpreting my opposition to OP's claim that "Some people apparently just can't stand to have anyone driving before them" as me arguing that it's fine for drivers to mow down cyclists to save 5s.
> just that the cartoonishly evil caricature of the driver's reasoning that OP dreamed up isn't accurate
"Cartoonishly evil"?!?
I'm pretty sure it is accurate for some subset of the driving population, which was the claim.
> Unfortunately, judging by the downvotes it seems like people are interpreting my opposition to OP's claim that "Some people apparently just can't stand to have anyone driving before them" as me arguing that it's fine for drivers to mow down cyclists to save 5s.
You didn't actually provide any evidence or argument to dispute that claim and completely ignored the key "risky" part of comment.
The way it reads is that you had your feelings hurt by having your bad behavior called out and felt a need to rationalize that behavior.
>I'm pretty sure it is accurate for some subset of the driving population, which was the claim.
It might be true, but that's not the same as "accurate". Let's imagine the same thing but for cyclists:
"I saw a cyclist run a red light and I had to brake to avoid T-boning him. Apparently some cyclists hate motorists and want inconvenience them as much as possible."
I'm sure there's probably "some" radical cyclists that utterly despise motorists (think /r/fuckcars) and want to go out of their to inconvenience them, but only mentioning that as a possible reason for the behavior is at best an act of omission. There's probably some far more innocuous explanation out there, like that the cyclist thought the way was clear (because there were no cars in sight).
>You didn't actually provide any evidence or argument to dispute that claim and completely ignored the key "risky" part of comment.
It's totally fair game to criticize one aspect of a comment even if you agree with the point broadly. For instance, I might not like what facebook's privacy record, but still object to comments that claim that facebook is bad for privacy because it's surreptitiously listening on people's phones.
> It might be true, but that's not the same as "accurate". Let's imagine the same thing but for cyclists:
I don't understand the disctinction you are trying to draw here. The statement itself is both accurate and true? At best the implication might be slightly hyperbolic but definitely not a "cartoonishly evil caricature."
> There's probably some far more innocuous explanation out there, like that the cyclist thought the way was clear (because there were no cars in sight).
Except your explanation is also not innocuous. Not wanting to be behind a bicycle is non an excuse for dangerous passing and especially when you are approaching a red light. The fact that you think this is an acceptable reasoning for that behavior is why you're being called out and downvoted. None of your excuses for how this might cause a light cycle to trigger sooner make this acceptable behavior.
> Seems like the far more plausible reason is that drivers don't want to be held up by a cyclist traveling at 10mph in front of them?
Their reasoning is as follows:
see cyclist -> cyclist always slow -> must always overtake cyclist
Empirically, 99% of drivers act according to this simplistic model. They do not take the situation at hand into consideration at all, they simply always try to overtake cyclists.
The speed the cyclist is going at doesn't matter, the upcoming intersection/roundabout/traffic jam does not matter, the minimum legal (and safe!) distance from the cyclist while overtaking does not matter.
Sounds like they never heard of Goodhart's law. They rigged a system which measures behavior (distance of approaching vehicle) and tied it to decision making (controlling a traffic light) in order to create an incentive toward a certain desired behavior. That's a prime example of something where people will learn the system and game it to optimize their own advantage instead of the desired behavior.
Thanks for explaining, because the OP made it sound like the red light tricked you into wastefully shedding speed instead of letting you stay at the speed limit. Their language makes it sound like they view slowing traffic as intrinsically good, rather than just trying to prevent speeding.
I should have been clearer on two behaviors. What I describe is if you are "alone". Green light often (not everywhere) don't stay green if there is no car. But if there is traffic, it is made in such a way that when you get a green somewhere, you can expect every subsequent intersection to turn green when the head of the traffic arrives. So the first vehicle will see a red light turn green as they approach, and the ideal timing is around the speed limit. Further cars will have a green light, but with no intensive to speed as they are sandwiched between cars.
Also I should say that this is empirical evidence based on about 20 intersections I pass often. I don't know how much of a rule it is country wise as I don't pay attention to that when I go places I don't routinely go.
Hard disagree here. Use it. Of course, if you running code that drive a pacemaker or a train maybe be careful, but in general, do things. We don't want a world where only three old bearded guys can write a compiler or a physic engine. Do the same errors again and you'll learn, eventually you'll do better than those who were here before you.
Well don't do it and instead of using an off the shelf library that is known to work while the rest of the development team isn't reinventing the wheel.
Doing it for fun and education is fine of course.
What IS the right way to model dates in a pacemaker ...? I hope the answer is "just don't do it" -- but I don't know what reasons there might be for a pacemaker to need to depend on calendar dates in order to best do its job ...
Well naturally it will need to connect to your phone via Bluetooth for the app to proxy update downloads and historic location data uploads. But in order to do anything on the network securely you need an accurate clock and the ability to parse datetimes because the PKI implementation depends on that.
Then the app pings you to remind you that your premium subscription will be expiring soon after which your heart rate will be limited to 100 bpm or less.
Hopefully no real pacemaker manufacturer is allowed to do that. Creating radiation in the middle of a body near a critical organ without a medical reason sounds like a really dumb idea.
Also you want the pacemaker to be as air-gapped and simple as possible, because it needs 100% uptime.
I still have a preference for OpenBSD.