Hacker News Reader

Comment by chunkyks | Hacker News Reader

I have a Jetson nano. It's a nice thing for what it is, and the price.

But, the software misses the mark by a lot. It's still based on Ubuntu 18.04.

Want python later than 3.6? Not in the box. A lot of python modules need compiling, and the cpu is what you'd expect. Good for what it is, bad for compiling large numbers or packages.

They run a fancy modern desktop based on the Ubuntu one. Sure, it's Nvidia, gotta be flashy. But that eats a quarter of the memory in the device and make the SOC run crazy hot all the time.

These aren't insurmountable issues, they just left a bad taste in my mouth. In theory I only have to do setup changes once, but it's still a poor experience

View on HN

> Want python later than 3.6? Not in the box.

The more I use linux (and I'v been for almost 15 years), the more strongly believe that using what the Linux distros provide as a development toolchain is an antipattern. Use separate toolchains with SDKs separate from your /usr instead.

> Good for what it is, bad for compiling large numbers or packages.

at worst you can

    docker run -it aarch64/ubuntu

on your desktop and compile your stuff there.

u can use virtual environments for that

Perhaps virtual environments should be the default on Linux distributions?

In the case of 'Python Virtual Environments' you'd still have to install another version of Python which is non-trivial with Debian based systems without causing some sort of collision, unless you download the binaries to /usr/ or other bin location as suggested.

I like to use pyenv for this purpose, as it "virtualizes" Python versions by installing them locally as you mention. Then you just point each virtualenv at the Python binary for the version installed via pyenv. pyenv + virtualenv + virtualenvwrapper have greatly reduced Python dependency issues for me.

A bunch of programming languages do a little bit similar like Node has Node Version Manager or nvm, I think Go has GVM, Rust just has Rust Up, they usually install in your home folder and let you swap between versions globally, I've yet to have to do this as I usually spin up a VM if I know I'm going to need to deploy to a very specific version of Debian / Ubuntu, a virtual environment might not match behavior on the actual target system but a VM definitely will.

+1 to pyenv. And it's even better if you combine it with pipenv [1]: pipenv manages dependencies its own file (Pipfile) which can also specify the required Python version. Pipenv integrates with pyenv so if the required Python version is not available it will offer to download and install it.

Tldr; with pyenv and pipenv installing a Python project is just "pipenv install".

[1] https://pipenv.pypa.io/en/latest/

I would strongly recommend taking a look at Poetry as an alternative to Pipenv.

Pipenv is honestly a nightmare.

I regret I can only upvote this once. Pipenv still gets press, but I'm not sure why. Every senior dev I know switched to Poetry long ago.

I have been using pipenv only on a couple of projects and for a few months, but it has been an improvement over pip and virtualenv.

Why do you say Pipenv is a nightmare? Have you had bad experiences with it?

Especially in the case of a python virtual environment, "conda" solves everything ultra cleanly (regardless of whether it's debian, fedore, arch or Windows and probably macOS too though I didn't try).

It provides any version of Python, regardless of what your base system has (or lacks). It also provides an isolated gcc and many other packages; and you can still "pip install" inside it if the package you need is not conda-native, and conda will track it just as well.

Conda is really underappreciated.

It's totally trivial. ubuntu 18.04 has packages for python3.7 and python3.8 which install to /usr/bin/python3.7 and /usr/bin/python3.8, leaving /usr/bin/python3 pointing to /usr/bin/python3.6. So, you'd type:

`sudo apt -y install python3.7`

Then:

`mkvirtualenv --python $(which python3.7)`

It really is that easy.

Please take a look at Nix. I think you will like it.

I totally agree, at least on the desktop. My /usr isn't required for any of my customers' projects to run, and it probably shouldn't be - I have environments and VMs and containers for all that stuff.

But this is an SBC. It's likely to be configured to run its specific task forever. It should automatically log into the default user's account, and automatically start whatever software you want it to run. Software for it is likely to come from cross-compilers and to be sent over SSH.

It doesn't have hundreds of gigabytes of high-speed storage, the entire OS needs to be copied from a microSD card on every boot, so you don't want to have multiple toolchains on it.

I really like the DietPi [1] environment for these purposes (though it doesn't currently support have the Jetson Nano), the setup scripts make it easy to configure the OS for exactly the tools you want.

[1]: https://dietpi.com/

> The more I use linux (and I'v been for almost 15 years), the more strongly believe that using what the Linux distros provide as a development toolchain is an antipattern.

Your assertion makes no sense. Let me explain why.

You've adopted a LTS release which was made public 2 years ago, was already a couple of years in the making, and is aimed at establishing a solid and reliable base system that can be targetted by the whole world with confidence.

And knowing that, your idea is to bolt on custom tooling that's not installed anywhere or by no one by default and make it your own infrastructure?

Unless you're planning on managing that part of the infrastructure for your customers to use, your race to catch up with the latest and greatest makes zero sense, and creates more problems than those you believe you're solving.

And no, it's not an infrastructure problem. It's a software engineering problem that's yours in the making. If you seek stability and reliability then you target stable and reliable platforms, such as the stuff distributed by default by LTS releases such as Ubuntu 18.04. because that's what they are used for.

> You've adopted a LTS release which was made public 2 years ago, was already a couple of years in the making, and is aimed at establishing a solid and reliable base system that can be targetted by the whole world with confidence.

From my experience, 0.05% of the people who have an Ubuntu x.y chose it because of "stability promises" of the LTS release. They just want a quick linux install to run their shit on, or it was handed that way by the Uni department / company / whatever. Or just because it's the biggest name and you're sure to find help online. And then a lot of people don't upgrade - I work with my fair share of people running win 7 (even still have an XP person around), OS X < 10.10 and Ubuntu 14.04, just because they can't afford newer hardware required to make the experience of newer OSes not a laggy shitfest.

> And knowing that, your idea is to bolt on custom tooling that's not installed anywhere or by no one by default and make it your own infrastructure?

gcc is not part of infrastructure, just like Xcode.app or Visual Studio aren't part of Windows or macOS infrastructure.

gcc is part of the infrastructure, for the simple reason that you need the same compiler version to build Linux kernel modules.

> for the simple reason that you need the same compiler version to build Linux kernel modules.

Which kernel modules wouldn't come as precompiled packages in Ubuntu ? (real question - as an Arch user for instance I haven't had the need for DKMS for years)

DisplayLink is something that comes to mind. For Arch (btw i use) it needs DKMS and comes out of the AUR[0]. For Ubuntu, it looks like you need some 3rd-party packages that will need to be compiled for modern kernels.

[0] https://wiki.archlinux.org/index.php/DisplayLink#USB_3.0_DL-...

> From my experience, 0.05% of the people who have an Ubuntu x.y chose it because of "stability promises" of the LTS release.

Your experience and my experience differ greatly, then. I manage around a hundred virtual and bare-metal Ubuntu 18.04 LTS systems. Most of our docker containers (not included in the number above) are based on an Ubuntu 18.04 image because that's what we have standardized our infrastructure around.

The LTS choice was an easy one to make. We are too busy focusing on delivering value to the business to spend much time constantly playing around with the underlying technology. We are not early adopters for much of anything (except hobby projects at home) because we need our technology to be an asset to the business rather than a liability. Depending on new and bleeding-edge software for production systems just creates unnecessary risk.

We'll probably start thinking about upgrading to 20.04 in six months or so.

> We are too busy focusing on delivering value to the business

there are a lot more linux users out there than business users

This disagreement is why multiple distros exist. Ubuntu LTS is a reasonable choice for entities that want stability and are willing to accept the occasional migration cost of upgrading to the next LTS (note: this applies to lots of desktop users as well as businesses). Fedora and Arch are reasonable choices if you want cutting-edge software, but come with risks as software changes under them.

> there are a lot more linux users out there than business users

maybe, but there are a LOT more linux servers out there than linux users, if by "linux users" you meant "people running linux on their computers".

those servers (and the people that run them) generally require stability.

would you care explaining what you mean? is it not fair to say that there are many orders of magnitude more instances of linux running on servers than there are instances of linux running on people's home or work computers? that is indisputable, no?

It makes as much sense for me to count individual servers than to count individual docker containers. It's the amount of people administering those systems which matters - having many servers to manage just means that you have to know how to setup automation

> We are not early adopters for much of anything (except hobby projects at home) because we need our technology to be an asset to the business rather than a liability.

I'm really glad there are still companies with such values. For some strange reason, these days people equate innovation with using fancy/barely tested tools.

> From my experience, 0.05% of the people who have an Ubuntu x.y chose it because of "stability promises" of the LTS release.

You might be right, that %.05 of people choosing to use LTS distros are doing so for its service promises. But I'd counter that the majority of those who care are managing hundreds or thousands of machines / users. The end users might not know that they care, and that's because the admins are doing a good job.

> and is aimed at establishing a solid and reliable base system

Excellent, I have a solid base.

Now I want to install the latest version of Gimp. Cannot. Why is that tied to the base versioning?

Why do you believe you can't? Because, I mean, you can.

The more I use linux (12 years), the more I believe that common users should not use "stable distribution". Upgrade is risky, software is always outdated. It solves nothing and provides unjustified feeling of stability.

LTS makes sense as deployment platform. Push it to server and deploy own application. Make a demo like subject NVIDIA Jetson Nano SDK and forget about it.

There are better ways to help underpowered machines - use light desktop environment, block ads in browser, add RAM if possible. Kernel and base requirements has not changed much in a decade. About 120 MB with XOrg.

this feels like mass cowardice to me. run Debian testing or unstable. run something semi modern. not old lame vendor LTS.

those who cower in LTS land, thinking they are saving themselves from troubles have very very very little experience, scant little too contribute to the community that cares & tries to remain mildly up to date. there is such a prevalent fear based mentality about running decent reasonable modern upstream software but it is such FUD, such a cannot do attitude. rarely can these camps justify their afraid behavior. LTS is nonsense. testing, unstable, they work well, & they expose real honest levels of support for systems, versus relying on antiquated but known support that LTS brings the tepid adopters.

It is in the name, marketing, people use Debian Stable, Ubuntu Long Term Support, they don't use Ubuntu Outdated. But that's what it is. The moment it moves to Stable it does not receive versions update. We can't force rename. Maybe we can come up with better names for "testing", "unstable"?

* Fresh

* Upstream

* Rolling

I understand people don't want to switch distribution, channels out of fear, inconvenience. Can cross-platform package manager help? The one with dependency resolution — Nix, not the one that bundles it all together like Flatpak or Snap.

this is godforsaken mother-of-all-anti-pattern sinful words. how terrible! don't trust the distro, don't trust upstream! trust only the particular bizarre awkward vendor tool chain? gods no. heavens no. the only reason, the only places this advice is ok is when your hardware is unsupportable, un-un-streamable, when the hardware embodies an anti-supportable form of existence. @jcelerier's advice here could not be more antithetical to the real story. if you need custom weirdo toolchains, something has gone direly wrong.

FWIW, I got a review unit and it ships with a much lighter desktop environment (LXDE) this time and is has a swap file enabled by default. I guess that was needed to ship a 2GB version, but overall it seemed a little better thought out. They also include a wifi dongle in the box.

It still only has Python 3.6, but OpenCV and numpy are pre-installed correctly this time so you don't have to compile them which is an improvement.

You can update it to Ubuntu 20.04 pretty easily. (using a Xavier as a desktop with that)

If you don't need CUDA, you can outright use regular Fedora, which uses nouveau. (no reclocking issues or such on Tegra)

If you don't need CUDA, then save money, heat, and support issues associated with a second-string product and just get a rpi4. The entire point of the Jetson is that there's a non sucky GPU that can do AI at the Edge.

Perhaps we would be better off if NVidia just made GPUs for the RPi ...

They are trying to purchase ARM, so I wonder what that means for Mali...

I did switch mine to LXDE, but it was a faff to do and took ages. I imagine the only way to make this thing slower is to swap to an SD card.

I'm not doing anything with mine that involves OpenCV, I didn't realise one of its flagship examples was also messed up in the box.

Oh! And I just dug out my script to rebuild if I need to. I forgot a few more annoyances:

* tensorflow isn't installed by default, and it's not obvious how to do the install because you have to specify NV's repo: pip3 install --pre --extra-index-url https://developer.download.nvidia.com/compute/redist/jp/v44 tensorflow

* openai gym won't work unless you specify archaic version 0.15.3, there's a buggy interaction between it and NVidia's X11.

* lots of packages need installing that should really have come by default, or were broken by default [eg numpy]

Do you know who I could contact to request a review unit? (if you can share ofc - email in bio) I have an open-source Jetson-related project that I think the new model could be useful for.

Email me (info in bio) and I'll see if I can help

I use SBCs extensively, bought Jetson Nano as soon as it was available, I'm convinced that none of the SBCs in the 4GB Memory space are fit to run in the desktop mode and removing desktop packages to make more space for headless mode is the first thing I do after installing the OS.

I doubt that it largely has to do with the lack of optimisations of the graphical packages in the Linux for ARM architecture, as a x86 Chromebook with 4GB memory and slightly better CPU clock boost rate can offer far superior desktop experience.

I think there are (in general) two models that work.

1) ubuntu lts - stable releases - I'm a server person I want nothing to change, ever.

2) arch linux - rolling releases - I'm a desktop person, I want the latest of everything, now.

anything between these two extremes kind of sucks, both as a developer and as a user.

advantages:

1: "Q: I want to disable snapd on ubuntu 18.04, how do I do it?"

"A: <20 detailed posts of how to do it>"

1: "user: something isn't working"

"developer: clearly your fault, I haven't changed anything in that project in 4 months"

2: "Q: I want to disable snapd on arch linux, how do I do it?"

"A: why did you install it? look on the wiki."

2: "user: something isn't working"

"developer: everything is up-to-date, please do pacman -Syu and read the wiki"

18.04 is a sensible release to ship, considering that 20.04 only came out in April.

I would guess because the NVIDIA driver/library support on 20.04 is still lacking.

I just set up a new 20.04 for ML and the official NVIDIA repos for this version were still missing a few cuXYZ libraries. I had to also add the 18.04 repos and symlink them together to get some Frankenstein library mess that works (as far as I can tell).

Wait, what? That really surprises me. I am using CUDA 11 on NixOS unstable (which is a rolling release) without any issues at all. Or is that on Aarch64?

Jetson is still on CUDA 10.2 which only supports fully GCC 8 and earlier.

Support for CUDA 11 is coming soon, with the bump to Ubuntu 20.04 at the same time too. However, patching those issues isn't very problematic.

I'm not going to lie, I don't understand the usage of Python and other such languages in the embedded space in general.

This is not really the classic embedded space; it is a full ARM processor running a full linux operating system. Its more like a small server than a MCU board. It couldn't be used for hard real-time requirements.

This are fully blown computers with plenty of ram and using python on them is just fine if it meets your cpu usage spec. People get too carried away with the term embedded. Not everything is an MSP430 with a tiny bit of memory or processing power. That said, I've been using modern c++ and rust on my hobby projects as they have most of the advantages of python and blow it away as far as memory usage and performance, at least for embedded usage where we're not building huge web apps or similar.

Rapid prototyping and in the case of Jetson - computer vision and Tensorflow running on the GPU. Both have excellent support for Python.

Sure you can make those things run natively but people using them are used to Python, lot of code is written in Python for it and there is little to no performance penalty of running the code in Python (everything perf. critical is running natively anyway, Python is only used to "glue" those bits seamlessly together).

And once you have RAM in gigabytes even the extra memory overhead of Python becomes a moot point.

In this particular case, I think everything compute-intensive happens in the GPU anyway, so there's not much to lose by using a high level language on the CPU side.

Can you not trivially update all these things though? Like how big of a deal is it really? Or are you stuck using their specific distribution, and their distribution can't be updated to a more recent Ubuntu and python?

You can update things but in my experience it wasn't trivial

Is it just the normal process for updating Ubuntu to the next release though? I wouldn't call that trivial either, but only because it'll likely take hours here. Still, it's a well-trammelled path that typically works well and while unattended. So if that's all it is it doesn't seem like a huge deal.

I run Debian (mostly) on it. Seems to work well for me. Compiling PyTorch is a bit of a nuisance at 4GB, but it worked. One issue I had was that TRTorch wanted bazel to build and I couldn't bring myself to install that (and Java), so I made up some quick and dirty CMakeLists.txt and it worked well.

But I must admit I don't see the 2GB model as a better value than the $100 4GB one, especially with shared CPU/GPU.

> Want python later than 3.6?

apt-get install python3.7

apt-get install python3.8

That might theoretically trigger updates of packages on which NVidia stuff depends (through indirection), which will then render your system unusable. You might be lucky, though.

An alternative is to use Docker containers or similar.

that's why you look at what's getting install before you hit go. anyway it's easy enough to backup and restore almost all these SBC's

I think it'll be all right. python3.8 is its own distinct package, which will install alongside the existing python3.6.

Debian/Ubuntu's "alternatives" system can select what /usr/bin/python3 runs. In practice, changing that away from the distribution default can break other people's code, and the win of an LTS is not spending time on that stuff.

But you can get yourself a Python 3.8, then you can build venvs, run a Jupyter kernel in it, whatever you like. If you can download or rebuild all the modules you want in a 3.8 venv, you're pretty set. And everything wanting Python 3.6 on your LTS still works.

That will most likely break OpenCV, Tensorflow and CUDA which depend on binary packages compiled for the given version of Python.

CUDA doesn't depend on python, it's the other way around. And you'd install the new versions of those packages.

What I meant is that it would break the CUDA package for Python and support in things like Tensorflow, obviously. Not CUDA itself.

You can't just "install new version" of those packages unless Nvidia supports it, unless Tensorflow supports it, unless OpenCV works with it. If you have ever tried to build Tensorflow from source, you would know what I am talking about.

I have, on python 3.7, and it works fine with the entire CUDA matrix from 10.1 to 11. So your point has theoretical merit, but in practice, it's not a real problem as compatible versions of those packages are readily available.

Yes, NVidia should stop tying their Jetson hardware to specific Ubuntu releases.

Instead they should release drivers that work with any Linux distribution (for example Debian, which is now broken because of USB issues).

I just installed python 3.8 on my Ubuntu 14.04... Had to also upgrade openssl and lzma for it to be useful though

Also, no ffmpeg with hardware acceleration. They force you to use gstreamer.

ffmpeg with hardware acceleration is available, see: https://github.com/jocover/jetson-ffmpeg

(there's also the NV prebuilts of an older version of the patchset at https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%252... )

Just curious, any guess why it doesn't come with the latest Ubuntu and Python pre-installed?

NVidia don't see the point. There are a few forum threads where NV respond "why do you even want that" or "you can get ubuntu 20.xx from a third party".

Then why pre-install anything? I'm not in the field, but I would think that a lot of people would want to run there Python CV code on it. Or is it, becaue they want you to use CUDA?

Because if you don't have an offering that'll make it do something interesting OOB, it's unlikely anyone would buy it. [bootstrapping from true scratch is typically a nightmare for hobbyists]

I shouldn't be quite so negative; NV did put in a lot of effort building up the development kit. ARM Builds of CUDA, drivers, etc. Repos with packages for the job. Tutorials for common tasks, etc. They're really within a hair's breadth of an excellent OOB experience, but fell at the last hurdle.

The raspberry pi didn’t/doesn’t ship with anything and people bought/buy that by the millions

It’s very easy to install any version of Python using pyenv. I would be careful not to change the system Python in 16.04 because it will probably mess up apt.

As soon as you start needing C libraries, you start getting minor issues here and there. Numpy modules in particular seem prone to issues -- even on a bog-standard x86 desktop. It's got to be much worse on the very niche Nvidia SoC.

18.04 was the last Ubuntu LTS before very recently, and python3.6 is system python3 for Ubuntu 18.04. These are both Ubuntu examples that Nvidia just left as the default. When 20.04 comes python will upgrade with it.

Reply on news.ycombinator.com