UMetaGOMS's comments

In some cases, no. In most cases, it is more accurate to say that I don't anticipate other people in the org being considerate, due to a lot of the interactions we have being one-off rather than an ongoing relationship.

This is the #1 reason I have not entertained the 4-day week idea myself. While I'm confident my productivity per day worked would be at least as good and my post-tax finances would be fine, I don't trust my colleagues or customers to respect the boundary.

100% agree. I have a NAS for photos and media, plus a big USB HDD for ZFS snapshots of my machines - but all of this is homelab tinkering, not an actual backup strategy.

I realized in the last year or so that the only digital media I have which I would be genuinely sad to lose were wedding photos - so I saved those to 3 different cloud providers, made a Blu-ray copy, and a copy on the NAS. If I lose all of that in some tragedy, chances are I've got bigger things to worry about.

I feel like I do more for open source by not contributing - given my staggering incompetence, I'd only make things worse.

I think you might be replying to the wrong comment, as this doesn't really relate to my point at all.

I don't disagree with the sentiment that RHEL also controlling the free alternative doesn't make sense. I do disagree with repeated assertions that people can just use RHEL for free - for the most part, they can't.

There is no evidence that RHEL will be releasing a free version to replace CentOS, and the fact that others will take over a replacement OS development is already known.

My comment was focused on the confusion/exasperation at why people keep implying this is no problem, because we can just use RHEL for free, as that is not true.

People I'm dealing with seem to be concerned that Canonical/SUSE might pull the same stunt. Personally I think the backlash RH have created is enough to discourage either company from following this path.

People keep saying this all over these threads, and I can't grasp why.

The difference is that a free RHEL without support doesn't exist, while CentOS does.

You can get RHEL for free through various developer focused programs, but that is most certainly not the same as having an unencumbered ISO available for unlimited downloads with no EULA or sign-in requirement.

To put it another way, European culture values humility over ego, and does not applaud those who manage to exploit those "lesser" than themselves quite so much.

I am definitely guilty of chasing some fusion of prestige and money, with no greater goal. It has recently become a concern to me that I really can't pick out anything more worthwhile than my current FAANG role as a "thing to do with my life"... and yet observing from the inside has shown how underwhelming and borderline dysfunctional these companies can be.

Cannot upvote this enough. I'm sure a frequent Java user will come along to tell me how easy it is - but at this point I'm not interested in delving into their world. If a new application I'm looking at is a single binary I can drop on my system (a la Go/Rust) then great - otherwise it has to be something I really need for me to not just resort to "whatever is in the package manager, or find a different solution".

As someone who doesn't do software development as part of routine day-to-day work but has played with both, I'd describe Julia as "Fortran for Python developers", while Nim feels like "C for Python developers".

My interest in scientific applications pushes me towards Julia, but the user experience has so far been strictly worse than than Python, so I just don't bother with it as much as I might like to.

On the other hand, I am drawn to experiment with Nim (and to some extent Rust as well) because they feel better constructed, having more professional feeling tools and approaches to packaging. The downside is that their core strengths are in use-cases which aren't so aligned with my interests.

The strength of the Python packaging ecosystem makes me doubtful of the impact Julia can have. Meanwhile for Nim, it feels to me like awareness and adoption suffer a fair bit from competing with Rust for mindshare.

> faster than many LAPACK/BLAS implementations

IMO this is worth very little; as long as there is a heavily optimized version written in C/assembly (ie MKL), the fact that Julia might be faster than standard-but-slower versions like OpenBLAS doesn't actually gain me anything as a user.

Draw.io does everything I need for free, and is about 80% "good enough" in terms of output quality. I would love to use this tool for the aesthetic benefits, but would struggle to justify even $10 for the sake of ~1 diagram per month.

I very nearly bought an Oculus Quest recently due to some glowing reviews, despite my strong anti-FB feelings. So very glad I hesitated.

Last year sometime - I'm about due another look.

Main problems were cryptic errors in the REPL, super slow start-up and first run times (JIT issue I seem to recall reading was being improved), and a generally very poor third-party package management system.

On the last issue, I'd say Python is not perfect but pip and various virtualenv management systems are "good enough". Having something like the Rust/Cargo setup is what I would prefer.

They did that because Python has an appealing user experience for people using that kind of code day-to-day. IMO this is what Julia missed; I've tried it at least once per year since first hearing about it in 2014 and the UX was horrible every time. Pretty sure if I ever found myself needing to write low-level numerical code I'd just use Fortran like everyone else.

It's a real shame because Julia initially felt like it might develop to be the natural successor to Python in scientific computing, but over time that has seemed less and less likely.

AWS Braket is in preview, so should provide what you are asking for in the near future. QC hardware manufacturers generally also offer their own cloud access mechanisms.

Another AWS employee here.

I'm pretty indifferent to this. I've used Slack a few times for open-source projects and customer contact - it's fine, but I haven't seen anything which sets it apart besides mindshare. Hopefully access to the paid features will change my stance.

Chime gets a lot of flak, but frankly it's the best video conferencing tool I've used, so I'm glad that part will stay. The main downside to Chime as a chat tool is also IMO its biggest positive - the fact that no-one else uses it. I never had to be too mindful in Chime rooms about speaking out of school, but with Slack as the default for both internal and external communication that might have to change.