Vultr is pretty cool, but I was paying $10/mo for a 2 v-cores/2gb/55gb. I got a 'root server' with netcup and I'm now paying $11/mo for 4 cores/8gb/256gb nvm-e. Unfortunately the placement isn't what I hoped as it's in Virginia. I would've liked Singapore but the cost would be twice as much.
Yes, I feel like it'll be a degrade in quality if they do this with any of their current line up. If they want to make a Macbook Ultra or whatever with it, that's fine -- I would have no interest in it.
I have a magic keyboard for my studio, bloody expensive, but I just love the ergonomics and feel compared to my two TKL (really nice) mechanical keyboards.
I haven't been to a cinema in 15 years, but I went to view yesterday with Gold seating. Didn't even know you could get alcohol served to your seat these days.
might be, i wouldnt be sure but i would encourage author to dive a lil deeper based on some comments in the thread. Theres obviously lots to explore. Anything that goes into this topic is likely to make omissions, have some ,wrong viewing angle' or such things.
I just want to give a perspective of someone that uses the 'eternal history' in bash per Eli Bandersky [1] and reluctance to use something like atuin (without/ignoring shared history).
First, as for speed and responsiveness, if there is a degradation, it is imperceptible to me. I wouldn't have a clue that my interactive shell is slowing down because it is logging a command to ~/.persistent_history.
My persistent_history is 4MB and has been migrated from machine to machine as I've upgraded, it's never felt slow to edit with (neo)vim or search with system supplied grep.
Eli's way of doing it also includes the timestamps for all commands, so it's easy to trace back when I had run the command, and duplicates are suppressed. In fact my longest persistent_history goes back to 2019-07-04, so I've been using it for quite some time now.
But the larger point I wanted to make is that I wouldn't feel comfortable switching this, in my opinion, quite efficient setup to displace it with an sqlite database. That would require a special tool to drill through the history and search rendering simple unix utilities useless. As Eli suggested, if your history gets too big, simply rotate the file and carry on. I have the alias phgrep to grep ~/.persistent_history, but I can easily have another alias to grep ~/.persistent_history*.
I much prefer the parts pairing that is required by Apple. Parts pairing is a mitigation to theft, but in my opinion should be a stronger anti-theft measure. I don't think Apple goes far enough with this. At the moment, a locked part, that is a part that has been taken from a mac with the activation lock still enabled, should render unusable on another mac, or at least show up in the parts setting as marked lost or stolen, and should at render as completely inferior to that of a genuine or authenticated part.
This doesn't hinder repairability, as you will find with the Macbook Neo. It just thwarts a secondary market for stolen Macbooks and/or parts.
The same thing you'd do yoursef if you wanted to assign it to a namesake local variable even if it was in a dict to begin with: you'd make the dash an underscore.
It would be extremely unlikely that you would replicate the name as a local variable if it was in a dict, but regardless a dict doesn't have that limitation. The namespace thing is atrocious and bad design -- no straightforward way to iterate over them, merging/updating them is awful, collides with keyword methods (keys, items, etc.), and so on; thankfully more modern argument parsing libraries didn't repeat this mistake. It's just a shame this ended up in the standard library, but then Python standard library has never really been any good, e.g. logging and urllib1234567.
reply