Re: Debian Pinebook Pro
September 11, 2021 9:19 PM, "Vagrant Cascadian" wrote: > On 2021-09-11, Peter Ehlert wrote: > >> On 9/11/21 1:11 AM, Keith Bainbridge wrote: >>> On Tue, 7 Sep 2021 10:01:49 +0300 >>> Andrei POPESCU wrote: >> >> Andrei -- happy Debian user of a PINE A64+ and (still) considering >> the Pinebook Pro for my next laptop > > ... >> superior build quality, I really like it, but it is not my daily driver >> >> lurking here for tips on how to get Debian running on it. > > I gave a talk (that had some glitches...) at DebConf21 which has bits > and pieces of what I did to make a live image that boots on both the > pinebook and pinebook-pro: > > https://debconf21.debconf.org/talks/88-two-pinebooks-walk-into-a-bar > > with video available at: > > https://meetings-archive.debian.net/pub/debian-meetings/2021/DebConf21 > > And slides: > > https://salsa.debian.org/vagrant/two-pinebooks-walk-into-a-bar > > At some point I'd like to firm up the process for making live images for > arm64... but at the moment it's still a bit ad-hoc, though I've managed > a proof of concept! :) > > The next feature I need to work into it would be to add UEFI support, > then it could boot any system with UEFI as well as 1-3 systems with > compatible u-boot offsets... > > live well, > vagrant Awesome! Very much enjoyed seeing, and hearing, the talk, on and about my Pinebook Pro! With Kali/debian on PineBook Pro: Wifi works; sound works, not very loud, but loud enough to hear the talk; also has difficulty with suspend/hybernate and low battery. What was the purpose of providing a makefile instead of just a PDF of slides? I already had graphviz, but all the rest took "185 MB of archives" download, and used "605 MB of additional disk space," for 1.2 MB of PDF file? Now I is a developer/builder?!
Re: Debian Pinebook Pro
On 9/11/21 2:19 PM, Vagrant Cascadian wrote: On 2021-09-11, Peter Ehlert wrote: On 9/11/21 1:11 AM, Keith Bainbridge wrote: On Tue, 7 Sep 2021 10:01:49 +0300 Andrei POPESCU wrote: Andrei -- happy Debian user of a PINE A64+ and (still) considering the Pinebook Pro for my next laptop ... superior build quality, I really like it, but it is not my daily driver lurking here for tips on how to get Debian running on it. I gave a talk (that had some glitches...) at DebConf21 which has bits and pieces of what I did to make a live image that boots on both the pinebook and pinebook-pro: https://debconf21.debconf.org/talks/88-two-pinebooks-walk-into-a-bar/ with video available at: https://meetings-archive.debian.net/pub/debian-meetings/2021/DebConf21/ And slides: https://salsa.debian.org/vagrant/two-pinebooks-walk-into-a-bar At some point I'd like to firm up the process for making live images for arm64... but at the moment it's still a bit ad-hoc, though I've managed a proof of concept! :) The next feature I need to work into it would be to add UEFI support, then it could boot any system with UEFI as well as 1-3 systems with compatible u-boot offsets... live well, vagrant thanks for the input and encoragement
Re: Debian on Pine64 H64B?
On September 12, 2021 10:01:20 PM UTC, Oregano wrote: >September 12, 2021 3:19 AM, "Gunnar Wolf" wrote: here. >> >> But I understand you might have better preferences. Please provide me >> the details for a web space you will sponsor and keep for several >> years, and I will move raspi.debian.net there. Gunnar: can i ask: I take it that you, personally, are not comfortable paying for hosting bandwidth, out of your own personal funds, if the end-users who are downloading images do not themselves offer you any financial compensation or give you donations for doing so? do you ever receive any such offers that would aid and assist in covering the full cost of the hosting, or for your efforts in maintaining the server? >I was not trying to insult you because of your host choice. which i am sure he didn't take it as one. > Rather to give you feedback from my experience. which i am sure he appreciated. >out three to five times minimum before displaying, which takes several >minutes. You're free to take the feedback or ignore it. i do have to point out that you're both mis-communicating, here. Gunnar mentioned that you are free to provide an offer of an alterative hosting service - AND PAY FOR IT (or find a long-term sponsor) as a very polite way of saying, by omission and implication: "you get what you pay for... and you haven't paid me anything" in other words, he did not wish to risk annoying or insulting you by pointing out that your report, which is perfectly valid and most appreciated, did *not come with an offer to pay for improved service* this is one of the rather embarrasing and uncomfortable aspects of Free Software: the assumption that because it's Libre, it must also be monetarily zero cost. put plainly: hosting those images costs *real money*, for which someone has to pay! so please: if you find the service that Gunnar provides at no charge to yourself to be inadequate for your needs, *pay him to improve it*!!! [or, help him to find a sponsor willing to pay for better and long-term service, as he suggested] it's really that simple, folks! l.
Re: Debian on Pine64 H64B?
September 12, 2021 3:19 AM, "Gunnar Wolf" wrote: > Oregano dijo [Sat, Sep 11, 2021 at 11:26:37PM +]: > >> >> OK, but nslookup raspi.debian.net and whois 208.97.148.173 shows >> raspi.debian.net is hosted at NightmareHost, which probably explains >> the very long delays in seeing the site sometimes. I respect >> Gunnar's support for raspi's, but the choice of host could be much >> better, IMO. > > Actually, I have been a DreamHost client for >20 years, and am quite > happy with them. They provide me more than enough bandwidth and > storage for basically every need I have come across for a very > agreeable price. That's the reason I hosted my images there. > > But I understand you might have better preferences. Please provide me > the details for a web space you will sponsor and keep for several > years, and I will move raspi.debian.net there. I was not trying to insult you because of your host choice. Rather to give you feedback from my experience. My experience with NightmareHost was, and continues to be, unsatisfactory. Not all slow sites I often visit are hosted there, but some are. Google's Speedtest says raspi.debian.net is fast, but knowing DH, they probably purposely slowdown access over Tor, and speedup access from testing sites. When I go to www.debian.net, it redirects to debian.org and displays a page within a second or so. When I go to raspi.debian.net, it usually times out three to five times minimum before displaying, which takes several minutes. You're free to take the feedback or ignore it.
Re: Debian is supported on many arm platforms
On September 12, 2021 2:47:38 PM UTC, "Andrew M.A. Cater" wrote: nice summary, Andy. a couple of things that i feel are important to add. first (i accidentally trimmed context) is about debian package distribution. for those people unfamiliar with it, who have been used to other package management being distributed via "trusted" website download (node, pypi, Mozilla B2G), debian CRITICALLY DOES NOT rely on or trust web sites or SSL Certificates in any way, shape or form. debian's distribution validation is *fundamentally* tied to the web-of-trust GPG keyring, which is itself signed and distributed as a debian package. if you are of the belief that the debian *website* or *domain* are the sole exclusive trust authority then you have left yourself open and vulnerable to attacks of many different varieties, too numerous to list here. please, therefore: trust and check the *GPG signatures*. >4. Other platforms may have more/less support: this is not for want of >effort >and a unified approach would be really very helpful. [This might need a >more standard approach to boot methods/co-operation from manufacturers >and is not something to be solved immediately]. second, is about this. sad to say, any expectations of collaboration from manufacturers is expecting far too much. shockingly, LG's Lawyers for example actually consider it to be a failure *on their part* if you even *notice* that LG's TV products have been criminally infringing copyright law for decades. Allwinner Chinese employees are paranoid about IP Theft by Westerners because they themselves do it all the time, and therefore expect Westerners to "punish" them by stealing or hacking their networks at their offices. yes, really. i was invited to visit the Allwinner offices a few years ago and the Chinese staff treated me like I was there to commit Industrial Espionage. i felt so unsafe as a result, i could not dare consider a return visit. from a product perspective, products involving ARM SoCs are *NOT* designed for user programmability "convenience". they're not even designed for the *OEM's* convenience! both Mediatek and LG have a policy of designing products *entirely on behalf* of OEMs. they design it, they program it, they deliver it. LG even *make* the damn products: the first time the OEM ever sees it is when it turns up at the Customs port! i am basically painting a picture here of the realities of ARM SoCs, which is that the Fabless Semi Companies are ACTIVELY HOSTILE to the entire Free Software Community. we are a THREAT to them. how DARE we reverse-engineer THEIR products and steal all THEIR secret commercial information! never mind the fact that without Free Software they wouldn't even be able to sell one single product: in their minds, one tiny change to one single header file is sufficient justification to flagrantly and blatantly ignore the fundamental tenets of Copyright Law. even those Companies that understand Copyright Law *still* do not wish to cooperate or collaborate because (a) it costs money to do so (b) it reveals commercially confidental information (c) it doesn't help sell product that (d) is *specifically designed for non-end-user-programmability in the first place*! much as i and everyone else is terribly frustrated with how badly the Free Software Community is treated by the Fabless Semi companies, expecting *any* type of cooperation from them *or from ARM* is unfortunately completely unrealistic. Roger spent considerable time kindly explaining how long it took to get Linaro established. Linaro is about the limit of what ARM can do, only working with *willing* participatory Fabless Semi companies to create standards. given the sheer massive diversity with literally thousands of ARM licensees, any attempt at "restrictive" standardisation is going to result in pushback and resultant loss of business for ARM. it's a shitty sutuation but important to understand the context, so that we do not, as a community, spend too much of our time either complaining or fighting or unrealistically wishing things were different. personally i am so absolutely fed up with seeing so much of *our* (collective) personal money going into "fixing" the mess that Fabless Semi companies leave behind that i concluded that the only way to properly fix it is to *become* a Fabless Semiconductor ASIC designer, and create an actual SoC that actually properly respects Software Libre to the bedrock (http://libre-soc.org) unfortunately, due to ARM's licensing model, it can't be an ARM-compatible design. we picked Power ISA instead. l.
Re: Debian is supported on many arm platforms
On Fri, Sep 10, 2021 at 12:40:49PM -0700, Vagrant Cascadian wrote: > On 2021-09-10, LinAdmin wrote: > > The unnamed decision makers of Debian some unknown time ago > > decided that Pi and *Pine* stuff won't be supported by Debian. > > This is the second time you've stated this, without really adding > meaningful content to the conversation, and people have presented > evidence to the contrary... > > If you don't want to help, that's fine, but please at least refrain from > making repetative, vague statements of questionable accuracy. > > Debian Developers and many other contributors to Debian are in fact > supporting these and many other platforms on Debian... They have done so > by submitting patches, bug reports, fixes, etc. It would be difficult to > create a comprehensive list of all of them. Check the changelogs for the > linux kernel, u-boot, debian-installer, raspi-firmware... there are lots > of people making decisions to support these platforms in those and even > other packages. > > Specifically... > > There are at least five pine64.org platforms listed at: > > https://d-i.debian.org/daily-images/arm64/daily/netboot/SD-card-images/ > > I believe the same set of images is supported in the Debian bullseye > release. At some point they worked (I personally tested each of them > before adding support), if they don't currently work, please file bug > reports and ideally patches if you can. > > > While the Raspberry Pi can't fully be supported in Debian "main" due to > the Debian Social Contract and the lack of compatible licenses: > > https://www.debian.org/social_contract > > There is support for the non-free firmware in "non-free" since 2019: > > https://tracker.debian.org/pkg/raspi-firmware > > More recently, you can get a UEFI implementation for pi3 and pi4: > > https://github.com/pftf > > With a UEFI implementation, you can boot the standard debian-installer > .iso images for arm64 platforms: > > https://cdimage.debian.org/debian-cd/current/arm64/iso-cd/ > or > https://cdimage.debian.org/debian-cd/current/arm64/iso-dvd/ > > And there are "unofficial" images made to be written directly to boot > media produced by Debian Developers available at: > > https://raspi.debian.net > > > > Somewhat of an aside, I feel inclined at this point to bring up the > Debian Community Guidelines: > > https://people.debian.org/~enrico/dcg/ > > I find it has some valuable thoughts that help improve my contributions > to Debian. > > > live well, > vagrant You got in there on the Community Guidelines just before I did :) This has been a long thread: I think there's something to be brought out of this - let's see if I can summarise some of the back and forth. 1. There _is_ support for the Raspberry Pi in Debian. There are unofficial images from raspi.debian.net maintained by Gunnar Wolf. They're unofficial for the reasons outlined by Paul Wise: containing non-free firmware. 2. These images use u-boot and dtb primarily. There are images for all currently released Raspberry Pis. The earlier Pis are not compatible with the later Pi architectures necessarily - Debian does things differently to Raspbian. [it's an interesting point that they could be put into cdimage.debian.org in the same way that unofficial firmware images for amd64 are already there. Likewise, almost certainly for the next alternative - certainly something to consider.] 3. An alternative is to use the UEFI approach from Pete Batard for Pi3 and Pi4 specifically. This doesn't use dtb by default and uses ACPI. It's a rebuild of Tianocore. Provided you have the firmwrare, it does allow a user to use an unmodified Debian arm64 image to install everything else. 4. Other platforms may have more/less support: this is not for want of effort and a unified approach would be really very helpful. [This might need a more standard approach to boot methods/co-operation from manufacturers and is not something to be solved immediately]. Support for Pine / other Allwinner platforms / other boards may sometimes be difficult for reasons outside Debian's control. 4. There's scope for all approaches: more help is always appreciated. At times, it felt like contributors to this discussion were talking past each other inadvertently whereas they've mostly been in violent agreement. 5. There is always scope for better communication and, certainly, better understanding of where we are, how we came to reach this point and for everything to be better documented. LinAdmin: The "decision makers" from Derbian aren't unnamed: they're primarily the developers and others who've chipped in on this discussion. Opinions vary, as you've read, but your help would be appreciated. If you're not in a position to help, please relay the accurate information from this list. Your cooperation in this would be greatly appreciated. With every good wish to all, as ever, Andy Cater
Debian hosting and bandwidth
On September 12, 2021 4:00:08 AM UTC, Jeffrey Walton wrote: >I'm not sure how IONOS compares to DreamHost for network bandwidth, >however. We have not (yet?) encountered a problem with throttling. ah. mythic-beasts.com very kindly explained this one to me. the majority of ultra-cheap hosting VM providers oversubscribe CPU, RAM, and bandwidth, often to a massive degree. in the case of CPU and RAM that is done through VM Ballooning, and it means that if the main host happens to have someone else consuming vast resources, *you* get punished. likewise during heavy overall network usage, you get punished for *other people's* excessive bandwidth. mythic-beasts make a point of *NOT* doing that. when they say you get 1 gigabit per second service, you GET 1 gigabit per second service, AT ALL TIMES. likewise for RAM and CPU, you get what you pay for, 100% of the time. for hosting something like debian packages it therefore does not make a lot of sense to use sub-standard hosting with ballooning and shared oversubscribed bandwidth because it's going to be a massive sustained load. ISPs are often happy to sponsor the debian project to provide bandwidth and hosting, they get kudos for doing so plus they're probably using it for their own infrastructure. l.
