diegs
You can find older generations on eBay very inexpensively for what they are, install Ruckus Unleashed firmware on them, and operate them completely locally.
They have the best beamforming antennas in the industry and their firmware is rock solid. I'm on some very old models (2.4ghz and 5ghz only) but they work fantastically well. I'll probably upgrade to some wifi 6 models soon.
But for my uses 500-600mbps rock solid throughout my house is plenty. Anything where I want max throughput/low latency/low jitter (mainly gaming) is hardwired. For wifi I care much more about complete and consistent coverage.
I'm going back starting on monday, so I'm curious to try out jj.
In the past 10 years it's all been github and gitlab, and their code review tools are so painful, specifically w.r.t. tracking discussions across revisions. I never felt excited to try out jj because I was afraid it would that situation even worse.
Yi was kind of designed like this, I believe. You could compile in an emacs-like model, a vim-like model, or presumably make your own model.
I've used Helix and Kakoune in addition to Emacs and Vim, but dealing with the limitations/featureset/plugin treadmill gets a little tiring.
I have been following Zed, and it seems that they have rearchitected things to enable adding Helix mode and making the editing model a bit more modular, but it's still fairly new. They are fixing bugs pretty quickly. I will have to try it again.
They have a nice discussion here:
https://github.com/zed-industries/zed/discussions/6447
They reference Ki, which also looks cool, and they out some of Helix's inconsistencies in their comparison: https://ki-editor.github.io/ki-editor/docs/comparisons/
I prefered Kakoune to Helix (it was more consistent). But to your point, being able to swap these things out more easily would let you choose an editor based on features, and not tradeoff between features and an ergonomic editing model.
Ironically you can use Ki inside of VSCode (and I know you can use Vim that way too), but VSCode is so darn bloated and slow...
https://tailscale.com/blog/more-throughput
Not sure if the kernel implementation pulled ahead again, I don't really follow these things.
Also not defending tailscale, I respect them but I agree they are a one size fits some solution.
It also may take longer to have an effect than is commonly said. For me, it's ~3-4 hours. I'm a natural night owl but 0.3mg melatonin at 6pm has me falling asleep on the couch at 9:30-10pm.
I actually have a few old Nest hubs sitting in the basement…
Really, I just want our smart displays (which I paid real money for) to show our family photos and do smart home things. It's exhausting to repeatedly have to open up the settings panel and uncheck whichever new screens/"experiences" they've added each time they start popping up. There are dozens at this point--talk about shipping your org chart!
Hopefully Matter will mature at some point and Apple will ship some smart displays of their own, and then we can toss our Alexas in the bin.
This feature turned on for me today, and ignoring the problematic 1984-ish implications, it’s also nudging me very hard to change my writing style.
I’m not a perfect writer or close to it, but I’m not bad. Part of my word choice is what makes something written by me distinct from something written by someone else. I’ve accepted and even embraced some of these idiosyncrasies. Hilariously the system seems to have a hardcore vendetta against the word “sophisticated” despite it being a perfectly cromulent word in the context I was using it IMHO.
I’m just ignoring the suggestions (as a google PM would certainly suggest in defense of this feature) but I’m sure many people won’t, and all our writing in docs will start to look and sound the same.
I think that focusing on either side alone can lead to biases and problematic science, and focusing on both is actually the most "fun"
I'm glad this is being made, but like many other things that have been added to Go, it shows the limitations of the language that you can't just build this inside the language. (I might be wrong, as I haven't had a chance to look at the design docs/implementation yet, but the installation instructions imply that's the case).
I agree that VW and other manufacturers are going big on EV platforms and cars, but (in the US at least) until there is a viable competitor to the supercharging network, I will go with a Tesla.
It's like iPhone vs Android in the early 2010s. "It just works" is actually worth a lot, vs all the quirks you'll have to deal with for the non-Tesla alternatives.
Instructions: https://medium.com/@mrtcve/at-t-gigabit-fiber-modem-bypass-u... Github project that makes it possible: https://github.com/jaysoffian/eap_proxy
It's definitely not plug and play but I've been using this setup for a year and a half and I get my full 1gb bandwidth throughout my network with lots of hosts.
The remarkable thing to me is that Apple is working so hard to distinguish itself from other competitors about how much they value privacy. Tim Cook famously said, "privacy, to us, is a human right [1]." I wonder how (or even if) they'll acknowledge this one and walk it back. Hopefully more articles like this will ring even more loudly.
Sending all this stuff via plaintext is just plain scary. I've never worked at Apple, but from my experience at other big tech companies, this would never pass a rudimentary security/privacy review (which surely this had, given the scale that this feature is operating at), which leads me to believe it's intentional.
On the other hand, given how badly it crippled people's computers, perhaps it was just really poorly engineered. I think Apple's response (or lack thereof) could be really significant. I don't own any Apple hardware, but am still keen to follow this story.
1. https://medium.com/@profgalloway/no-mercy-no-malice-apples-c...
* People are home all the time, so they have plenty of time to do chores and work. I know for many people "WFH day" is "oh look, I have a pile of laundry I'll just take care of really quickly..." day.
* People don't have as many social options, so even if you're not as focused as you might be at the office, you also have more time to throw at work "after hours"
* People can't cut out at 3 or 4 or whatever to go do fun things or start their weekend early, so you don't get the "WFH today because I'm taking a flight this afternoon" days which essentially are days off
This is based on observation about myself and colleagues. I don't think we have evidence that once things return to normal people will be as productive as home (I don't also see evidence that people are being particularly productive right now--it's just too soon to see the long-term effects).
This is of course based on small sample sizes of my observations and anecdotal, but it's also not speculation and seems to line up with a lot of other people's observations too.
I also agree with a lot of the comments around this being yet another way to push the cost ($ and otherwise) to employees. You now need to furnish your own home office, find ways to get the kids out of the house, etc.
Remote work can and does work, but I think it's situational on all sides (people that have the aptitude for it, companies that are invested in making it work, types of companies/roles where it can work)
https://www.npr.org/sections/money/2019/03/22/705914833/epis...
I think the problem is that the system has historically obfuscated a lot of the malpractice.
So I think the real reform is more transparency (body cameras and other things) to make sure infractions are actually exposed.
1. vi is everywhere, and...
2. vi with no plugins is still super powerful, which is helpful on random hosts / coworker's machines / basically anywhere, and...
3. since vi is still so powerful out of the box, i only need a few lightweight plugins to close the loop and make the most powerful editor i can imagine needing. 99% of my plugin usage is fzf and ale w/lsp, which are arguably two very powerful plugins, but the cognitive overhead is very low, and at least among peers my editor doesn't seem to be slowing me down at all
i would also pose the controversial opinion/hot take that using a less "powerful" (non-IDE) editor helps you write better code. humans can only fit so much into their working memory at a time. vim doesn't really let me do crazy refactors or jump through endless chains of class hierarchies (well, with lsp it can, but...). compared to my eclipse/intellij days (and codebases worked on by other people using those tools) i am forced to tame complexity by defining good module boundaries and abstraction barriers.
I'm saying this as someone who has helped a large organization of primarily Python programmers onboard with Go. Proper error handling is already something people don't do well (until we enforced lint rules throughout the company, there were already way too many `f, _ := os.Open(...)` types of error dropping).
I'd much prefer something more strongly typed with respect to error handling, rather than less. Like if Java had disallowed extending RuntimeException so all exceptions would be part of function signatures (and therefore have to be caught).
One thing I disagree with is the remark about having fewer, big packages. Though conceptually I agree that avoiding having too many public APIs that aren't widely used makes sense, in practice--at least on the types of projects I tend to work on--I find that directing people to split things into a few packages forces them to think about a decoupled design with good APIs between the components. This could certainly be done with discipline inside a single package, but unless everyone working on the codebase is very diligent about this it's easy for abstraction leaks to creep in.
Ultimately it's a judgment call, but I think an earlier paragraph (copied below) is far more important than optimizing on having fewer packages or fewer exported types and functions, especially (as is also pointed out in the doc) you can use `internal` subdirectories to make APIs project-private if you are writing a library that is consumed by other projects, as opposed a service.
> A good Go package should strive to have a low degree of source level coupling such that, as the project grows, changes to one package do not cascade across the code-base. These stop-the-world refactorings place a hard limit on the rate of change in a code base and thus the productivity of the members working in that code-base.
You can also easily search the back catalog of recipes if you don't fancy the current week's meal plan.