Crosspoint is very popular and very easy to flash onto the device.
Locking and preventing flashing of firmware only happened in China.
HN user
Crosspoint is very popular and very easy to flash onto the device.
Locking and preventing flashing of firmware only happened in China.
I picked the X4 over X3 because the usb-c is convenient for charging (which you barely need to do)
I love it and use it every day.
This article makes the assumption that Bob was doing absolutely nothing, maybe at the Pub with this friends, while the AI did all his work.
How do we know that while the AI was writing python scripts that Bob wasn't reading more papers, getting more data and just overall doing more than Alice.
Maybe Bob is terrible at debugging python scripts while Alice is a pro at it?
Maybe Bob used his time to develop different skills that Alice couldn't dream of?
Maybe Bob will discover new techniques or ideas because he didn't follow the traditional research path that the established Researchers insist you follow?
Maybe Bob used the AI to learn even more because he had a customized tutor at his disposal?
Or maybe Bob just spent more time at the Pub with his friends.
All of those terminals work for you now because someone went and added terminfo to ncurses which distributed it across all versions of linux.
Kitty needed to do it too back in 2018.
https://lists.gnu.org/archive/html/bug-ncurses/2018-09/msg00...
Note: Ghostty follows the same pattern as Kitty where they a) use their own terminfo, b) distribute it when ssh'ing (it gets pushed to the remote server) and c) added it to ncurses so that it will eventually go away.
| In the linked speed demo one command was 8 milliseconds faster than another. Ok?
For day to day, ls'ing files that speed up won't matter too much. It is when you are tailing logs or working with multi-gig files that it matters.
I think you've done an excellent job running the community for Ghostty and it is a prime example of how to do it right. From the Discord to Github repos you've been a class act all the way through and have pushed folks to be good, civil internet denizens. Much respect.
If anyone cares to search through Github, they will see loads and loads of Issues and PRs created by Mitchell in many of the related Open Source projects that Ghostty uses/references. From zig to kitty to supporting libraries, Mitchell has been trying to get the terminal community working together and have some sort of standards. A lot of them are like "X does this, Y does that, why are you doing it this way? Can we all do it this way?" and then having Ghostty follow the most reasonable solution (or supporting several!).
Tailscale ssh is very useful when away from your home network. Setup was pretty easy and the only 'gotcha' that I found was you cannot assign ssh to a mac machine if you are using the gui app. No worries though as it was easy to get tailscaled running with nix-darwin.
I am often away from my home network and my main gaming machine is asleep. I worked around this by installing tailscale + tailscale ssh on my router (yes you can to this!) and using it to send a wake-on-lan packet to my gaming machine.
Some useful fzf code for anyone that wants to get a listing of tailssh machines.
tailscale status --json | jq -r '
.Peer[] |
select(.Tags?[]? | contains("tag:dev")) |
"\(.DNSName)"' |
sed 's/\.$//' |
fzf --ansi --border-label="| Tailscale SSH Hosts |" --height=30% -- border=rounded \
--margin=2,2,2,2 --prompt "Connect to: " --preview-window=top:40% \
--bind "j:down,k:up,ctrl-j:preview-down,ctrl-k:preview-up,ctrl-f:preview-page-down,ctrl-b:preview-page-up"I am 47 and I am the best I have ever been. I might code slower than people 20 years younger than me but I produce much much better code than they do.
There is definitely ageism out there. What you don't get in velocity, I make up in quality.
Also, I think I am wise enough to know that I know nothing and there is still a heck of a lot to learn!
I've used everything. Windows for gaming/work, linux for prod/home and now Mac for work/play. I use docker every day and it's performance on Intel Mac used to be pretty terrible.
Until the M1 came out. It hands down beats every machine I have ever owned. I have an M1 Air, no fan, 10hr battery life, tiny package. It is amazing hardware. Docker is fast on it. Not linux fast but fast enough to always be running a dozen containers.
I find the recommendations saying that 'the software on mac is terrible' to not be the case for me. Sure, I am not running a fancy Wayland/sway tiled setup but the MacOS desktop is not THAT bad; at least it is not Windows.
I mostly use open source software every day. Alacritty (terminal), neovim (IDE), zsh (shell), firefox (browser), obsidian (docs). Spotify, slack and zoom are pretty much the only applications that are not open source.
I use dotfiles and use brew/brewfile to install packages. Brew has problems but apt/yum/etc have problems too. If you really want to keep things clean then you can use Nix on Mac if you wish.
And the Apple ecosystem? It just works and that is all I really care about. I put in my airpods and they can connect to all my devices. If I need to share files I can just air drop them to whatever device I want or just let them sync with iCloud.
I don't have time to fight with technology as I want to spend that time building things or hanging out with the family.
I think Asahi linux on M1/M2 laptops will be pretty amazing in the next year and you can have the best of both worlds.
I disabled the checker on startup because that dialog was annoying me.
In /config/lazy.lua:
checker = { enabled = false }, -- automatically check for plugin updates
I've never had a problem with the things you mentioned but the notifications are using either noice or notify. I think the submenu is <leader>snaThere are a couple things:
- Most distros seem to like wrapping functionality and having you use their own convenience functions to get things done. For example, for AstroVim, astrovim.<function> is all over their config files. This is fine if you were a distro developer and you were trying to make things easy for yourself but I do not find it easier for the user when neovim already has simple lua based functions. It is another barrier to entry as you have to learn how the distro authors put things together. - The config for LazyVim is will thought out. For example, it has 2 directories: /config & /plugins. That makes it simple to figure out where things should go. keymaps go in keymaps.lua, options go in options.lua... it kind of makes sense. - The plugin config for disabling a builtin plugin is the same as where you would configure your own plugins. It is literally:
return {
{ "github/plugin.nvim", enabled = false },
}
vs return {
{ "github/myplugin.nvim", {config here if you want}},
}
- There are no weird plugin loaders and most examples you see from plugin authors are copy/paste into that bracket section.
- The LazyVim website is decent. Not perfect though. https://www.lazyvim.org/
- The starter is a great place to start your setup. https://github.com/LazyVim/starter
- The plugin manager, lazy.nvim, seems to be a lot simpler and well thought out compared to others plugin managers (like packer). It has autoloading, caching, a UI, etc.
- Folke, the distro creator, has written many popular plugins and knows quite a bit when it comes to configuring plugins. That seems to be paying off in the design.To be fair, there are some design decisions that I don't agree with when it comes to the LazyVim layout itself. Putting everything in editor.lua or ui.lua instead of per-plugin config is not how I would have done it. It was pretty easy to figure out where the plugin settings were though because they match the categories on the website.
Note: I mainly switched to Neovim as I am find that there just seems to be much more development in the ecosystem and the number of amazing plugins coming out is staggering.
Please help the community and make sure that these issues are documented in Github/whatever issue tracker.
Or if you have the skills please contribute back and fixes these things that bug you!
That is too bad. If they did then they would probably garner huge community support and the gaps would be quickly filled in.
I have played with helix and I do like how it comes with everything out of the box. Helix is doing great things but it isn't there yet.
I can customize Neovim the way I want and the plugin ecosystem is huge. Maybe when Helix gets there it will be worth the switch.
p.s. kakoune style of modal editing makes so much sense and I wish vim had started out like that.
I've re-built my neovim config like 3 times this year as I have played with several 'distributions' and styles. SpaceVim, LunarVim, AstroVim, and NVChad to name a few.
This last weekend I gave LazyVim a try and it is by far the most sane config setup I have used and I will now be sticking with it.
There is a starter repo where you clone it, delete the .git directory and start customizing.
https://github.com/LazyVim/LazyVim My config is here, feel free to copy/steal it. https://github.com/curtbushko/nvim
I've only had successful paired programming in one situation and it was amazing. I believe it worked because we were friends and at the same knowledge level. In three days, we ripped through a project that should have taken a month. Our 'C' code was perfect because there was always someone looking at it in real time and catching the errors on the spot.
I do not think that I will ever encounter this level of productivity ever again.
Yes, it is "foot the bill" in regards to paying for it. My mistake but I am glad everyone had some fun learning!
The same goes for huge open source projects like Kubernetes. The amount of money to run the infrastructure for CI/CD and CDN is in the millions per year. Someone has to pay for that and the big companies are the ones that fit the bill. Google mostly pays for it but others have started contributing also. For example, Amazon recently announced that they are funding part of the infrastructure also.
I recently noticed a decline in battery on my M1. It is ridiculous to complain about 10h battery life but the decline was noticeable. I fixed it by:
1) Turn off siri suggestions & privacy and all the app watching it does. System Settings -> Siri & Spotlight -> Siri Suggestions & Privacy. It turned it off for every app.
2) Turn off siri all together. System Settings -> Siri & Spotlight -> Ask Siri Toggle
3) Turn off Spotlight for everything you do not need. System Settings -> Siri & Spotlight -> Search Results check boxes
4) Turn off login items. System Settings -> Login items. Remove what you do not need from the list.
5) Turn off run in background items. System Settings -> Login items -> Allow in background
6) Remove items from ~/Library/LaunchAgents/ that you do not need. I had an old docker vnet item that wasn't needed.
Other than #6, you can do the first 5 things on all of your Apple devices and it makes a big difference in battery life. I just did the same steps with my phone and ipad.
I hope this helps your battery life a little bit.
Folks tend to get so upset about the title of "DevOps". I am unsure if it is because of:
- just dealing with bad Ops engineers at work that "don't do much"
- employees taking advantage of the DevOps movement to make more money
- System Administrators complaining that 'this is what we have always done'
System Administrators, though skilled, had a much different mindset in the 90s when I worked closely with them. They were more focused on keeping Sun hardware running and keeping the SAN from filling up. That server room was their 'production'. They were still on call for when a server went down and it took days for a new server to be rebuilt. The best of them wrote scripts to make their lives easier but that wasn't often the focus. They were too busy keeping the systems running to automate much of it.I find that DevOps is a different level of abstraction compared to Sys Admins. In general, they do not need to know how to build a server and fight with the OS as they can use tooling to spin up 100s of machines in the cloud. The amount of knowledge they need is much broader and less specialized than a System Administrator. Where the Sys Admin would need to know the ins and outs of Cisco Routers, the DevOps engineer only needs to know how to use a Load Balancer. If lucky, there is a tool that makes it easy to create them.
I find the list in the guide to be quite accurate but you do not need to be a master of everything in the list.
I use hop only for specific characters using `HopChar1`.
My example was for non-prod and saving money there as I found that our development clusters tended to be the most under utilized per dollar spent. In development it was ok to put as many idle pods as possible on the nodes. If there was a spike, then yes you could get new nodes but I found that they scaled down nodes quite often.
My apologies in advance as the advice can be terrible depending on your environment and services. Below is not an exact science as you are dealing with requests and limits while trying to find optimal performance.
For production you need to calculate your minimum, average and max CPU/Memory for your a pod.
1) Set your replicas to 1
2) Determine what your true maximum CPU/Memory is for a pod.
Set your limits to very high and performance test against your pod. If your response time slows to a crawl then your limit is too high and your code may not be able to handle the load. If your response time is good while hitting the limit, increase the limit until performance goes down.
3) Get your minimum CPU/Memory for your pod to start.
5) Get your average CPU/Memory DURING THE SPIKES. You should be able to get this from past metrics. This can also be difficult to get because your load might be spread over several pods in your metrics.
6) I use the following formulas:
requests = (min + average)/2
limits = (average + max)/2
7) You now have a baseline for the future so that you can tweak the values.
8) Set your autoscaler to something high like 80% CPU. You want this value to stay constant. I think GKE sets it to 60% but I found that to be far too low and wasteful.
9) Observe and tweak the values to see if you can get things 'better' depending on your needs.
There are two other things I always do in production that help with stability and reliability. - Set the autoscaler behaviour to scale up quickly and scale down slowly. It stops these cycles of add 3 pods, remove 1 pod, add 2 pods, remove 3 pods chaos in short periods of time during spikes. The behavior field was added to the autoscaler resource a couple releases ago.
- Set your minimum replicas to 2 for redundancy. I always do this in production.
I hope this helps and I apologize once again for the hand wavyness of things.As someone else mentioned in the replies, this sounds more of a problem of not having a top level design than a naming problem.
You have bigger problems if your `PaymentService` morphs into the functionality of being a storage or user service.
Think of the new people you hire!
It is difficult enough being onboarded to a new company without having to learn two dozen names for random services and libraries. I feel sorry for each batch of Interns that start at companies that do this. Not only were the Interns learning how to build software but they also had to learn random names that they would not be able to use in their next placement.
What is easier to understand at first glance?
Picard stopped responding to Luke. Bilbo is also down!
or
PaymentService stopped responding to UserService. Database-XYZ is down!
It might not be exciting but the cognitive load is much lower.
HPAs can definitely save you a lot of money when running Kubernetes and they are extremely useful, especially for non-production environments where you want to be efficient as possible.
Strategies I have used in the past for saving money are:
1) Set requests very low for your pods. Look at the minimum CPU/Memory that your pods need go start and set it to that. Limits can be whatever.
2) Set min replicas to 1. This is a non-production environment, nobody cares if an idle pod goes away in the middle of the night.
3) Use spot instances for your cluster nodes. 80% savings is nice!
4) Increase the number of allowed pods per node. GKE sets the default to 110 pods per node but it can be increased.
5) Evaluate your nodes and determine if it makes more sense to have `fewer large sized nodes` or `several smaller nodes`. If you have a lot of daemonsets then maybe it makes sense to have fewer large nodes.
6) Look at the CPU and Memory utilization of your nodes. Are you using a lot of CPU but not much memory? Maybe you need to change the machine type you are using so that you get close(r) to 100% CPU and Memory utilization. You are just wasting money if you are only using 50% of the available memory of your nodes.
7) Use something like knative or KEDA for 'intelligent autoscaling'. I've used both extensively and I found KEDA to be considerably simpler to use. Being able to scale services down to 0 pods is extremely nice!To counter your argument. I did one full migration from AWS to GCP Kubernetes (GKE). The project was a huge success, simplifying our stack, deployments, logging, etc, etc.
We reduced our costs by 2/3rds, saving millions of years. Teams have been able to move onto feature work instead of maintaining custom deployment tooling. The Ops team 1/2 the size that it was before but is able to handle twice as many customers.
There are certain classes of work that are completely ignored by most companies such as build, automation, developer tooling and infrastructure cost cutting. These are not flashy features that you can show off to customers but they can pay in dividends year over year.
(Personally, I have saved millions a year in infrastructure costs and my promotions/compensation were not close to what a sales person would get if they brought in millions of recurring revenue)
Yes. I built an entire new platform on Google Cloud using Kubernetes (GKE). We moved from AWS.
It was a chance to re-architect the platform, make things simpler and cost effective. Huge success on all of those. Costs were reduced by millions a year.
Other than GKE, there was not a significant technology reason to move to Google Cloud. AWS didn't even have a managed version of Kubernetes at the time.
This article resonated with me as I have worked in a toxic startup environment that required 70+ hour work weeks. That company checked every box in the 2nd list:
- The market is not large enough right now. It was a huge market with huge incumbents with deep pockets
- The product is bad. A poorly designed product written by junior engineers
- Poor positioning. Fighting the big companies with no real value add is not a good strategy
- High competition. See above.
- Not talented team members. A rotating door of employees that leave in frustration.
- Poor alignment. Constant down time and everything is always on fire (hence 70+ hour work weeks).
- Poor founder. Definitely.
I still "work long hours" but not for the company. I enjoy technology and learning new things. I put in my regular hours for the companies I work for and my hobby is playing with other technology. I get to learn new things and my employers benefit. As an example, I learned kubernetes on the side. When the time came to build a new cloud platform, I was in a position to be the expert at it and was able to implement the platform for my employer, resulting in millions a year in cloud savings.I think you just take the cash using Stripe or whatever. It gets deposited in your bank account and you claim income tax on it.