| OERIAS | bonjour | 05:55 |
|---|---|---|
| lordievader | Good morning | 07:20 |
| ducasse | good morning | 07:26 |
| lotuspsychje | good noon | 11:02 |
| jeremy31 | Just heard a snow plow | 11:03 |
| lotuspsychje | its sunny here | 11:04 |
| jeremy31 | about 2 hours until sunrise | 11:04 |
| guiverc | grrr... I wanna write "You can't install 19.10 on a 32-bit only cpu" ... but I stupidly put 19.10 on a x86 box.. so I know it's ~possible (was anyway)... my doing that ages back now complicates? my wording... | 12:04 |
| SwedeMike | https://itsfoss.com/ubuntu-19-10-drops-32-bit-support/ that decision was reversed "Ubuntu Decides to Keep Supporting Selected 32-bit Libs After Developer Outrage" | 12:41 |
| SwedeMike | interestingly enough, Steam said they would not support 64bit on Ubuntu, but they started to support 64bit on MacOS | 12:42 |
| pragmaticenigma | thanks meonkeys waveform :-) | 21:01 |
| waveform | meonkeys, (continuing from discussion on device-trees); if you mean arm64 (rather than amd64) - sort of - the device-trees are usually generated as part of building the kernel and in the case of the pi that generates a whole pile of device-trees (for all models the built kernel supports) | 21:03 |
| meonkeys | ah, I did, thanks | 21:03 |
| waveform | meonkeys, e.g. if you have a look at the boot partition of a pi image (classic or core), you'll find a whole pile of .dtb files there (one for each model of pi supported) | 21:04 |
| meonkeys | so if I were to brutally summarize, having both ubuntu-core-18-armhf+raspi2.img.xz and ubuntu-core-18-arm64+raspi3.img.xz on http://cdimage.ubuntu.com/ubuntu-core/18/stable/current/ is a... shortcut until the device trees are complete so one ubuntu-core-18-arm64+raspi.img.xz could exist (or even one single ubuntu-core-18-arm64.img.xz ?) | 21:04 |
| sarnold | note that arm64 is a different instruction set, different sizes of thousands of datastructures, etc | 21:05 |
| sarnold | armhf is 32bit, amr64 is 64bit | 21:05 |
| pragmaticenigma | I think a part that might be missing with RPI discussion, RPI are system-on-a-chip (or SoC), where what really happens is there is an entire OS in the CPU. Raspian and Ubuntu talk to that OS in order to talk to the device's ports and components. That's why you have to define all those dtb's | 21:06 |
| waveform | well ... the device trees must've already existed to produce the image. However, and this is where I'm just speculating (all before my time), it's extremely common on most embedded platforms for one platform to be quite incompatible with another - it's *very* unusual to define an image that works across multiple embedded platforms, and I'm guessing the pi was treated like that initially, hence the core pi2 image, another pi3 image, etc. | 21:06 |
| meonkeys | (argh, missed that in my example one was arm64 and one was armhf) | 21:06 |
| waveform | however ... the pi is unusual in that instead of having embedded storage it uses uSD cards, and thus it's fairly common in the pi community to (in effect) rip your hard drive (uSD card) out of one machine, stuff it in another and expect it to "just work" ... but this is *very unusual* on most systems, and I'm not at all surprised that this was not considered originally when defining the images | 21:08 |
| meonkeys | ahhh... running Ubuntu on rasperry pis felt so much like a desktop I was ignoring the fact that it is SoC/embedded. Fascinating! | 21:09 |
| pragmaticenigma | waveform: I think it was originally the idea... but raspberry pi foundation hasn't been able to move away from the binary blob that boots the Pi yet. That is still being controlled by broadcom (or whome ever is making their ARM cpus) | 21:09 |
| waveform | however, given that things are actually a bit easier when we're having to maintain less images, and given that we've managed (almost) to get classic down to a couple of images (one armhf, one arm64) that effectively support all pis (that we support ... i.e. not the zero, but everything 2 and onwards), that's how we'd like to move core | 21:09 |
| waveform | pragmaticenigma, indeed - we're still using the pi's bootloader (albeit supplemented by u-boot, which is the basis of the A/B boot mechanism on core). But then the pi's boot sequence is *very* odd (for starters, it's the GPU that basically controls it!) | 21:11 |
| pragmaticenigma | that's what I was looking for waveform ... it isn't the arm cpu... but the gpu that has the binary blob/system os on it | 21:12 |
| meonkeys | so an intel nuc... that's _not_ an SoC computer, it's a traditional motherboard computer with, uh, multiple chips, right? | 21:13 |
| meonkeys | so I'm wondering why https://ubuntu.com/download/intel-nuc instructs me to get a core image for a particular NUC | 21:14 |
| meonkeys | I'm just not getting what makes Core different than, say server or desktop 18.04 LTS in this case | 21:15 |
| sarnold | ubuntu core uses snap as the only packaging mechanism | 21:15 |
| sarnold | if you're looking for "traditional ubuntu system" then you do not want the ubuntu core download | 21:15 |
| sarnold | if you're looking for a way to build kiosks or appliances or other iot-style devices, then ubuntu core may be a good fit | 21:16 |
| meonkeys | sarnold: right, I'm trying to get a layer or two down and understand the salient differences | 21:18 |
| waveform | meonkeys, on the core distro, until very recently, the definition of the machine (the "model assertion") could not be modified (which in turn meant that certain aspects of the boot sequence were "set in stone"); this is in contrast to the classic distro in which the package manager is free to modify pretty much anything it desires and install drivers for whatever you ask it to | 21:18 |
| pragmaticenigma | intel nuc I think also have APUs in them, where the GPU and CPU are on the same processor. But I think NUCs are closer to being a traditional computer, where they can still run a traditional OS on them... not 100% sure on that | 21:19 |
| meonkeys | gotcha. This is super helpful, thank you. | 21:23 |
| waveform | meonkeys, sorry that's all a bit vague - core is something I'm still digging into (most of my work has been on the classic side so far), but that's (part of) my understanding of the reasons for core's current setup on the pi | 21:23 |
| meonkeys | this is great, no worries | 21:24 |
| meonkeys | I work on a team that has deployed the classic os (16.04 LTS) to hundreds of computers in operating rooms, gathering surgical videos to help surgeons improve. I'm investigating core as a more secure/stable alternative to classic for these on-premise computers. | 21:25 |
| pragmaticenigma | meonkeys: My concern is RPi can do great video capture, but I don't think it works well for an extended period | 21:26 |
| meonkeys | we use NUCs, not RPIs | 21:26 |
| pragmaticenigma | I'm speaking to what sounds like a consideration of moving to RPi? or was that just in reference to the CPUs? | 21:27 |
| meonkeys | ah, gotcha. Yeah, I was just trying to understand all the different builds for core since we don't see that for classic | 21:27 |
| pragmaticenigma | ah, okay | 21:28 |
| * pragmaticenigma missed some of the first part of the discussion | 21:28 | |
| meonkeys | ah, so raspian must be more like classic? I just noticed you could run for example "raspian buster lite" on any RPI | 21:41 |
| pragmaticenigma | yes, raspian more in line with a traditional OS platform | 21:43 |
| pragmaticenigma | both varients | 21:43 |
| pragmaticenigma | lite just installs as a CLI only instance (no gui desktop) | 21:43 |
| meonkeys | cool, ok | 21:45 |
| tomreyn | !disco | 23:23 |
| ubot5 | Ubuntu 19.04 (Disco Dingo) is the 30th release of Ubuntu, supported until January 2020. Release Notes: http://ubottu.com/y/dingo | 23:23 |
| tomreyn | ^ outdated | 23:23 |
| jeremy31 | disco was a thing back in the 70's | 23:24 |
| tomreyn | :) | 23:25 |
| jeremy31 | When everyone got tired of John Travolta, disco died | 23:25 |
| ducasse | and then scientology got him | 23:27 |
| jelly | what's the codename for 20.04? | 23:42 |
| sarnold | Focal Fossa | 23:43 |
| jeremy31 | Frozen Fossils | 23:45 |
| akemhp | F*st f*ck :P | 23:47 |
| akemhp | I couldn't resist OFC, nm :) | 23:48 |
| jelly | so focal for the repo, thanks | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!