b5n

I've been running Debian testing for a long time, where I kind of expect things to break now and again; and I'm pretty surprised by your experience. The only breakage I've experienced were minor inconveniences, maybe it's familiarity with the OS? Modern Linux DE experience is quite good now a days.

I've never once ran into an issue with Fedora.

From the OP:

> For the complete list of changes and the people who made them, see the various ChangeLog files in the source distribution.

Surprised to see you downvoted on HN for being right. In a thread specifically regarding python typing you would think getting the basics right is kind of important.

I don't see the hype here, just use a statically typed language if it's an important consideration for the project.

Makes sense. I just use qwerty, side of palm for Ctrl and thumb for Alt. I understand if that's not intuitive to new users, but it becomes comfortable and efficient pretty quickly.

I find them incredibly ergonomic, another bonus is that it provides the same defaults found in most terminal emulators. Most people try to use pinky for Ctrl, or map to Capslock, but using the side of your palm for Ctrl is really comfortable. I generally run circles around colleagues in a terminal or working with text, especially when utilizing macros, but the learning curve is definitely steeper and took some time to get used to.

I'd like to see a pip freeze of whatever you're doing to consistently need venvs of that size.

Yes, but types not required.

  from numba import jit

  @jit
  def jitted_fn():

https://numba.readthedocs.io/en/stable/user/jit.html

Emacs:

  M-x pyvenv-activate

Or in your init:

  (pyvenv-activate "~/code/python/venv_dir/emacs_venv")

VSC:

  C-P
  Python: select interpreter

It's pretty simple, and claiming nuget, node, and cabal/stack as superior means you're either lucky or inexperienced.

What's wrong with using test in this context? If I'm running LTS, which for me is server only, I don't want or need newer kernel or x updates. Additionally, if I'm utilizing a DE I generally don't want LTS.

  sudo apt update && sudo apt upgrade
  sed -i 's/buster/testing/g' /etc/apt/sources.list
  sudo apt dist-upgrade

Getting security updates from unstable (not required):

1. Pin unstable lower than testing.

2. Configure apt/debsecan as outlined here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725934

> Debian awaits

Come on in, the water's fine!

> Mixing OLTP and OLAP becomes increasingly "normal"

Just because it's "normal" doesn't mean it's correct. Just because you can doesn't mean you should.

All hail bob1029:

> We aren't running any reports on our databases like this. I would argue it is a bad practice in general to mix OLTP and OLAP workloads on a single database instance, regardless of the specific technology involved.

I'd think strategically about a gap year. If you're a great student with excellent college prospects a gap year might make sense, admissions are going to be very competitive for 21/22. If you're not the best student it might make sense to try and get accepted for 20/21 due to smaller field of applicants.

That makes sense, if I'm in a terminal I'll just use vim, although I do get a lot of use out of eshell.

Probably in the minority - I have an extensive custom .emacs.d, but I've kept most of the default emacs bindings. Not only do I find them ergonomic (use the side of your palm for ctrl!), they're also the same bindings you'll find in most terminals. Additionally, emacs does so much more than editing, and having consistent bindings across tasks is really convenient (I'm super lazy :).

I'm confused by your workflow. Why are you opening a second Emacs instance?

In Emacs you just C-x C-f /path/to/config, for sudo C-x C-f /sudo::/path/to/config.

Starting location will be home, or the parent of the active file (if the active buffer is an editor).

I understand no one wants to deal with unexpected issues, especially when you're trying to get something done. Why not use virtual environments? You keep packages out of your system's python, and if you run into issues like above you can just recreate it:

  b5n:~/venv_dir$ python3 -m venv im_a_venv
  b5n:~/venv_dir$ . im_a_venv/bin/activate
  (im_a_venv)b5n:~/venv_dir$ pip install requests
  (im_a_venv)b5n:~/venv_dir$ pip freeze > requirements.txt
  (im_a_venv)b5n:~/venv_dir$ deactivate

  b5n:~/venv_dir$ python3 -m venv another_venv
  b5n:~/venv_dir$ . another_venv/bin/activate
  (another_venv)b@b5n:~/venv_dir$ pip install -r requirements.txt

Check out testing:

  sudo apt update && sudo apt upgrade
  sed -i 's/buster/testing/g' /etc/apt/sources.list
  sudo apt dist-upgrade

Getting security updates from unstable (not required):

1. Pin unstable lower than testing.

2. Configure apt/debsecan as outlined here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=725934

I reccomend https://kernelnewbies.org/ as a first stop for the curious (although I might also reccomend Emacs, contrary to their tutorial ;).

Surprised more people here are not using Salt. Having used both Salt and Ansible, I much prefer Salt, especially when working with larger teams.

When working solo I use Guix, both Guix and Nix are _seriously_ amazing.

No one wants to pay for parking.

Surf apps suck, they're generally asking around $10 a month, and they do little more than provide prettified weather buoy data.

_Decent_ wetsuits are in the $300 - $500 range, new board $600 - $1000. I think it's pretty capitalist to let some kook buy it new and then snag it from them off craigslist for %30 - %50 of retail.

Pismo looked healthier this year as well: https://www.parks.ca.gov/?page_id=23795

It was easy for me, no context switching. I assume basic use of grep and awk shouldn't be too much of a stretch for most Linux savvy engineers.

I'm happy TLDR fits your needs. I was just demonstrating how I use manpages effectively in hopes it might assist you.

It's just text - so all the text formatting/search/manipulation commands are available to you. Manpages are really easy to use and navigate, given you use them how they're meant to be used.

man man | grep -A 10 EXAMPLES

man tar | awk -F , '/-v,/ {print $2}'

man tar | awk -F , '/-v,/ {print $2}'

I use manpages frequently, seems easier to learn how to read manpages than create a new project dedicated to adding examples to manpages. I find them incredibly user friendly, but I cared enough to learn how to use them.

> How do you solve the "won't read my emails" problem ?

Just encrypt locally before sending.

Use what works best, but Emacs is incredibly powerful, and certainly has the potential to make you more productive. I wish I had taken the time to learn Emacs earlier in my career, my task efficiency has increased significantly since converting my work flows.

It does take a long time to learn relative to plug and play solutions (especially for someone like me with decades of old habits), luckily I had a few months off from work for the transition. The investment has been well worth it, it helps if you like lisp :)

Disclaimer: I use and advocate for tools derided above: linter/test integration, embedded features like autocomplete, etc.