2,843 karma · joined November 4, 2013
I’ve been a software engineer for the last couple of decades and I’ve tinkered with microcontrollers as a hobby but always been limited by my lack of electronics knowledge - very much trial and error to get a project far enough to be able to focus on the firmware (which is more my domain). I want to bridge the knowledge gap there.
My only formal electronics education was first year introduction to analog and digital circuits module at university two decades ago, led by a lecturer who assumed students had a huge corpus of pre-existing knowledge (and who I now suspect would have preferred to be supervising his PhD students and conducting research but had to make up the teaching hours - which I do understand).
I will definitely pick up a copy. However, Amazon UK (to avoid the NoStarch UPS shipping cost of $24) won’t get it to me until November. I’m excited to receive it.
Our users interact with a huge array of internal and external sites and web apps, virtually all of which will be tested on Chrome. Our LMS, collaboration tools, internal apps, SIEM tooling, HR systems, ERP, knowledge exchange partner portals - it's all been tested on, and works with, Chrome. And we're not in a position to force thousands of vendors to make sure their applications are standards compliant and work in less popular browsers (as much as we might like to). Not to mention the deluge of tickets we'd be dealing with when incompatibilities arise; banning Chrome would cripple us.
Google have backed us into a corner with this one by making a careless default choice that takes advantage of their market dominance and forces us to work around their decision.
As much as I’m against unexpected 4GB bloat for an AI model, I’d much prefer it to install one copy, system-wide. 4GB per Windows or Linux lab machine, rather than a 4TB minimum load on our NFS server and 4GB downloads per user, per machine on our Windows labs.
Fortunately as of Sequoia (15.4.1), I'm no longer able to reproduce the issue.
I’m sure some people would make the assumption that it’s under the same license as the upstream package but in some environments absolutely clarity around licenses is really appreciated.
“RR - What were FY96 [Financial Year '96] SW sampling limitations”
“RPG’s most messy” (with a superfluous letter in there).
On the most tightly managed lab machines, which are all in lockstep on a fixed configuration (latest Ubuntu LTS with a updated image pushed annually), we can provide a consistent Python setup (e.g. Python 3.10 and a fixed set of C-based modules like psycopg2). However, our staff and PhD desktops and laptops are more diverse - with the OS often only being upgraded when the distro is going out of support, they could be running n, n-1 or n-2. That, most likely, means three different Python versions.
We could use pyenv to let people install their own preferred version. Installing with pyenv requires building from source (slow on some of our oldest machines). This also means installing the Python build deps, which is fine for our departmental machines but not possible on the HPC cluster (operated by a different business unit) or the Physics shared servers. It's also less than ideal for our servers where students deploy their projects (where we want to minimise the packages installed, like the build-essentials meta package).
It's also a massive stumbling block for less experienced students with their own laptops which could be running any distro, of any age. Many CS101 or engineering/business/humanities students taking a programming class, who have never programmed before, would really struggle.
So, classes might tend towards teaching lowest common denominator Python (i.e. the oldest conceivable version a student might have installed on their machine).
Sure, we have in-person and remote lab machines students can use - but it's not always convenient (especially for the data science / ML students running Jupyter notebooks with their own GPU).
There are workarounds, but they all have serious downsides.
Compared with Node.js and Go, where users can just download the appropriate package and unzip/untar the runtime or compiler version of their choice, deploying the Python runtime has enormous friction (especially for less experienced users). This has the bonus of simplifying deployments elsewhere in our infrastructure (CI/CD, containers, etc).
And while we all complain about node_modules, Python venvs not being trivially relocatable is another huge frustration.
We've used Anaconda, but that comes with its own issues (most recently, finding that it ships with its own gio/gvfs binaries and libraries which fail to mount our CIFS DFS shares - causing confusion for users running `gio mount` from within a conda environment).