Re: Please upgrade your machines to sparc64
On 06/23/2016 10:38 PM, David Miller wrote: From: alexmcwhir...@triadic.us Date: Thu, 23 Jun 2016 16:12:35 -0400 1. Oracle knows sparc32 is faster than sparc64, that's why nearly half of Solaris is 32 bit. +1 Note that Solaris is providing more and more 64-bit binaries. Solaris libraries are always provided as 32 and 64-bit to ensure backward compatibility. But new Solaris binaries are usually 64-bit only. alex.
Re: Please upgrade your machines to sparc64
On 06/27/2016 02:38 PM, Alexandre Chartre wrote: > Note that Solaris is providing more and more 64-bit binaries. Solaris > libraries are always provided as 32 and 64-bit to ensure backward > compatibility. But new Solaris binaries are usually 64-bit only. Thank you! I hope that will finally clear things up a bit. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Please upgrade your machines to sparc64
From: alexmcwhir...@triadic.us Date: Thu, 23 Jun 2016 16:12:35 -0400 > 1. Oracle knows sparc32 is faster than sparc64, that's why nearly half > of Solaris is 32 bit. +1
Re: Please upgrade your machines to sparc64
On 2016-06-23 04:30, John Paul Adrian Glaubitz wrote: On 06/23/2016 07:54 AM, Alex McWhirter wrote: I spend most of my time working on pure 64 bit sparc linux. simply because that's where all the work is currently being done. That being said there are noticeable speed improvements with some applications being 32 bit. Where did I say that it is impossible to run 32-bit applications? I never claimed that! I never claimed that either. The point was that i work on 64 bit because it's what being actively developed / need implemented if linux for sparc want to have a future. As far as I know Debian doesn't really have a way of managing something like that.Sure you can compile everything both 64 and 32 bit and install whichever you want, but there's no way to really say one package should always be 32 bit while another should always be 64 bit. Even if that did exist sparc is the only architecture I'm aware of that would really benefit from it. Except that Debian has the best mechanism to resolve that which is called Multi-Arch. You can install libraries and binaries of *any* architecture onto *any* machine. In fact, I am doing that to cross-compile things like GHC, see: https://wiki.debian.org/DebianPorts/BootstrappingGHC Again, you're missing the point i was trying to make. A default install of Solaris includes a mix of 32 bit / 64 bit binaries depending on what the applications needs are. I can't think of any Linux distro that does that. Using Debian amd64 as an example, you get a full 64 bit system until you add i386 as an arch and install what you need as i386 binaries. There is no way that i know of (short of doing it all by hand) to build a single repository that has 32 bit applications / libs for some things and 64 bit applications for others. Short of building such to tool, the only option is to have a full 64 bit or full 32 bit userland and allow the end user to use a different ABI per application if they wish. If you build two repositories (one 32 bit and one 64 bit), there is no easy way to prefer 32 bit packages for some things and 64 bit packages for others. You can easily prefer entire repositories, but not each package within those repositories. The point isn't whether you can install packages for both ABI's. The point is that there is no current way to have a mixed 32 bit / 64 bit userland by default that is optimized based on a applications needs. Not without doing a ton of work by hand. My unofficial Gentoo ports support multilib for people wanting the best of both worlds. But making it a seemless experience providing the best performance based on each applications needs is something that would take a ton of work. It may not even be possible with the current packaging system. Multilib alone is an outdated and insufficient concept and the reason why we long had ugly solutions like ia32-libs in Debian which carried 32-bit versions of important libraries repackaged as 64-bit packages. These days, this has become completely redundant since you can just directly install i386 packages on an amd64 system if you need 32-bit support on x86_64, for example. Debian's idea of multilib != Gentoo's idea of multilib. This is mostly because Gentoo doesn't distribute binaries (except in very rare cases). Gentoo may have similar issues, but because all package are built from source i can just add "ABI=sparc32" to each package that doesn't need 64 bit support. However, it doesn't end there. You can even go further and install i386 packages on a ppc64el machine and run them seemlessly there through qemu-user. Although we are currently missing up-to-date 32-bit sparc packages which you could install on sparc64 via MultiArch (unless you want to use the old ones), there is nothing that stops you from setting up a small mini-dinstall server, set up an sbuild schroot for sparc and build custom packages for sparc instead of sparc64. Gentoo offers the same, but again the solutions they offer aren't as robust because they don't have to deal with the whole binary package aspect. One repo is good for all archs. Thanks to the Debian rebootstrap project [1], we are constantly making sure that bootstrapping sparc on Debian will still be possible if required. The project is still under development, but it's already possible to just cross- bootstrap sparc with current packages on any host architecture. Thus, I don't think any of the objections brought up against the sparc64 port are valid. Neither is sparc64 64-bit only nor does anyone anyhow prevent you in Debian to mix packages from different architectures. In fact, Debian has by far the most flexible approach to resolve the 32-bit/64-bit problem by providing a generic approach for mixing libraries of different architectures. Adrian [1] https://jenkins.debian.net/view/rebootstrap/ This wasn't supposed to be a "64 bit vs 32 bit vs debian vs gentoo" post... I really don't care what other people
Re: Please upgrade your machines to sparc64
From: John Paul Adrian GlaubitzDate: Thu, 23 Jun 2016 21:42:41 +0200 > On 06/23/2016 09:37 PM, David Miller wrote: >> We're not asking for the old "pure" 32-bit sparc port. >> >> Just a v8+ one, that doesn't support any pre-sparc64 hardware. >> >> Also a large entity doing something doesn't make it the correct >> thing to do. > > I'm out of this discussion. This is annoying. > > I'm not going to change my opinion on this. I'm not going to go against > the main flow. I am not getting paid for this, I am doing this completely > in my free time, so I don't understand why I constantly have to justify > myself. > > I have invested lots of time and effort to get Debian's sparc64 port to > where it is now and I'm not going to let this diminished by the naysayers. You can do a good job and do useful work for people, which you seem to have done. But your decisions are still up for criticism and analysis.
Re: Please upgrade your machines to sparc64
From: John Paul Adrian GlaubitzDate: Thu, 23 Jun 2016 21:33:34 +0200 > On 06/23/2016 09:31 PM, David Miller wrote: >> And all of those binaries you say "don't matter" take up memory, >> swap space, etc. And if you add this up for the entire system >> it's non-trivial. >> >> Multiply this by some factor N when virtualization is involved. > > On a machine with 8 TiB of memory? I have also never heard anyone complain > about memory issues on x86_64. Are you also running i686 for that reasons? It's physical memory, cache memory, TLB entries. Not the amount of physical or virtual "address space" the cpu supports. > Intel ICC does exactly that. I even provided a reference for that. I don't understand how such an optimization is even possible, or would even apply in common cases where the pointer is actually used.
Re: Please upgrade your machines to sparc64
Adrian, for what it is worth, I am very grateful for your efforts and fully support your path and approach. Wolf. Daum -Original Message- From: John Paul Adrian Glaubitz Sent: Thursday, June 23, 2016 2:42 PM To: David Miller Cc: baggett.patr...@gmail.com ; debian-sparc@lists.debian.org Subject: Re: Please upgrade your machines to sparc64 On 06/23/2016 09:37 PM, David Miller wrote: We're not asking for the old "pure" 32-bit sparc port. Just a v8+ one, that doesn't support any pre-sparc64 hardware. Also a large entity doing something doesn't make it the correct thing to do. I'm out of this discussion. This is annoying. I'm not going to change my opinion on this. I'm not going to go against the main flow. I am not getting paid for this, I am doing this completely in my free time, so I don't understand why I constantly have to justify myself. I have invested lots of time and effort to get Debian's sparc64 port to where it is now and I'm not going to let this diminished by the naysayers. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Please upgrade your machines to sparc64
From: John Paul Adrian GlaubitzDate: Thu, 23 Jun 2016 21:25:40 +0200 > As I have mentioned before, the work mainly targets modern > hardware. We are not doing this so that people can install Debian on > historic hardware. We're not asking for the old "pure" 32-bit sparc port. Just a v8+ one, that doesn't support any pre-sparc64 hardware. Also a large entity doing something doesn't make it the correct thing to do.
Re: Please upgrade your machines to sparc64
From: John Paul Adrian GlaubitzDate: Thu, 23 Jun 2016 20:42:31 +0200 > On 06/23/2016 05:06 PM, David Miller wrote: >> I think what irks people the most about what happened, is that the >> choosen a path is not the most optimal situation for the target >> platform. > > Why should it be any different for sparc64 than for ppc64el, amd64, > arm64, mips64el and so on? Is SPARC so extremely inefficient with > 64-bit pointers? I don't think so. It makes a significant performance and memory footprint difference. This is irrefutable. And all of those binaries you say "don't matter" take up memory, swap space, etc. And if you add this up for the entire system it's non-trivial. Multiply this by some factor N when virtualization is involved. > I don't think it makes sense to compile things like dateutils with > 32-bit pointers for performance reasons. Also, I would assume that > modern compilers are able to optimize the code well enough that the > difference between 32-bit and 64-bit pointers isn't too big that > it justifies the effort. No compiler is going to optimize away the pointers in the data structures, and thus get all of those cache line and tlb misses back. I do all of my work with 32-bit gcc binaries, even thought I often am using tools I've built myself. It makes a huge difference.
Re: Please upgrade your machines to sparc64
On 06/23/2016 09:37 PM, David Miller wrote: > We're not asking for the old "pure" 32-bit sparc port. > > Just a v8+ one, that doesn't support any pre-sparc64 hardware. > > Also a large entity doing something doesn't make it the correct > thing to do. I'm out of this discussion. This is annoying. I'm not going to change my opinion on this. I'm not going to go against the main flow. I am not getting paid for this, I am doing this completely in my free time, so I don't understand why I constantly have to justify myself. I have invested lots of time and effort to get Debian's sparc64 port to where it is now and I'm not going to let this diminished by the naysayers. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Please upgrade your machines to sparc64
On 06/23/2016 09:31 PM, David Miller wrote: > And all of those binaries you say "don't matter" take up memory, > swap space, etc. And if you add this up for the entire system > it's non-trivial. > > Multiply this by some factor N when virtualization is involved. On a machine with 8 TiB of memory? I have also never heard anyone complain about memory issues on x86_64. Are you also running i686 for that reasons? >> I don't think it makes sense to compile things like dateutils with >> 32-bit pointers for performance reasons. Also, I would assume that >> modern compilers are able to optimize the code well enough that the >> difference between 32-bit and 64-bit pointers isn't too big that >> it justifies the effort. > > No compiler is going to optimize away the pointers in the data > structures, and thus get all of those cache line and tlb misses back. Intel ICC does exactly that. I even provided a reference for that. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Please upgrade your machines to sparc64
On 06/23/2016 09:06 PM, Patrick Baggett wrote: > Just to adopt a devil's advocate approach here: I could also say that it > doesn't make sense to compile dateutils for 64-bit since extended address > space is no > use. I think the point is that there are advantages both ways: having a > single set of 64-bit packages is a lot easier to maintain, but David Miller > is correct > in saying that a large majority of packages do not benefit from using 64-bit > memory model, but all of them pay a "tax", relative to the 32-bit packages in > code > size, cache usage, etc. Obviously, for stuff like `ls`, I could care less if > took 250usec longer due to "64-bitness", but if somehow that caused my builds > to > take 5 extra minutes, I might get annoyed. I am doing the work in Debian and I am going to do it the way Oracle is doing it in their reference distribution. Not following the path that a huge company is already paving with lots of paid developers would just be inefficient and Debian's release policy requires that a release architecture has decent upstream support, both in regard of hard- and software. As I have mentioned before, the work mainly targets modern hardware. We are not doing this so that people can install Debian on historic hardware. > It's interesting to see, because from a maintainer standpoint, what you are > arguing makes a lot of sense, and from David's kernel developer standpoint, he > probably dislikes what he perceives as inefficient usage of the hardware that > slows down his workflow. It's not slowing down anyone's workflow. You are hugely overestimating the gain that using 32-bit pointers is bringing. > I'm also pretty sure that all of the incredible work you two have been doing > to iron out SIGBUS, fix drivers, and many other unspeakable violations of C > standards will translate to better code if there ever is more demand for > 32-bit SPARC packages. Like you said, it shouldn't be a problem to build / > upload > (32-bit) sparc packages, and then install them if desired, right? Debian has dropped "sparc" and it's not going to come back in the foreseeable future since upstream is focusing on 64-bit now. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Please upgrade your machines to sparc64
On Thu, Jun 23, 2016 at 1:42 PM, John Paul Adrian Glaubitz < glaub...@physik.fu-berlin.de> wrote: > On 06/23/2016 05:06 PM, David Miller wrote: > > I think what irks people the most about what happened, is that the > > choosen a path is not the most optimal situation for the target > > platform. > > Why should it be any different for sparc64 than for ppc64el, amd64, > arm64, mips64el and so on? Is SPARC so extremely inefficient with > 64-bit pointers? I don't think so. > > > The most desirable would have been to build the bulk of userland > > binaries as 32-bit with v8+ extensions (perhaps even with -mcpu=xxx > > for some v9 cpu), and then for the specific packages that need it, > > build 64-bit. > > I don't think it makes sense to compile things like dateutils with > 32-bit pointers for performance reasons. Also, I would assume that > modern compilers are able to optimize the code well enough that the > difference between 32-bit and 64-bit pointers isn't too big that > it justifies the effort. Some compilers like Intel's C/C++ compiler > are actually already automatically generating 32-bit code when possible, > the feature is called auto-ilp32 [1]. gcc could possibly adopt a similar > feature in the future. > > Just to adopt a devil's advocate approach here: I could also say that it doesn't make sense to compile dateutils for 64-bit since extended address space is no use. I think the point is that there are advantages both ways: having a single set of 64-bit packages is a lot easier to maintain, but David Miller is correct in saying that a large majority of packages do not benefit from using 64-bit memory model, but all of them pay a "tax", relative to the 32-bit packages in code size, cache usage, etc. Obviously, for stuff like `ls`, I could care less if took 250usec longer due to "64-bitness", but if somehow that caused my builds to take 5 extra minutes, I might get annoyed. It's interesting to see, because from a maintainer standpoint, what you are arguing makes a lot of sense, and from David's kernel developer standpoint, he probably dislikes what he perceives as inefficient usage of the hardware that slows down his workflow. I'm also pretty sure that all of the incredible work you two have been doing to iron out SIGBUS, fix drivers, and many other unspeakable violations of C standards will translate to better code if there ever is more demand for 32-bit SPARC packages. Like you said, it shouldn't be a problem to build / upload (32-bit) sparc packages, and then install them if desired, right? Honestly, I'm just happy to have a working kernel/userland/installer! That's a great base to launch any further operations, so thanks to both of you.
Re: Please upgrade your machines to sparc64
On 06/23/2016 05:06 PM, David Miller wrote: > I think what irks people the most about what happened, is that the > choosen a path is not the most optimal situation for the target > platform. Why should it be any different for sparc64 than for ppc64el, amd64, arm64, mips64el and so on? Is SPARC so extremely inefficient with 64-bit pointers? I don't think so. > The most desirable would have been to build the bulk of userland > binaries as 32-bit with v8+ extensions (perhaps even with -mcpu=xxx > for some v9 cpu), and then for the specific packages that need it, > build 64-bit. I don't think it makes sense to compile things like dateutils with 32-bit pointers for performance reasons. Also, I would assume that modern compilers are able to optimize the code well enough that the difference between 32-bit and 64-bit pointers isn't too big that it justifies the effort. Some compilers like Intel's C/C++ compiler are actually already automatically generating 32-bit code when possible, the feature is called auto-ilp32 [1]. gcc could possibly adopt a similar feature in the future. > And I would assume that would be perhaps binutils and perhaps gcc > and GIT. > > Yes, the 64-bit packages for everything should exist in the repository > and be built, but the default install should not have everything > 64-bit. I disagree. I think it makes way more sense to use such speed optimizations for code where it's really needed. That's also the most commonly used approach. For example, packages like ATLAS hugely profit from per-machine optimization which is why upstream doesn't recommend using pre-compiled binaries but build the packages from source. However, no one is going to see huge differences when building coreutils, dateutils and so on with 32-bit pointers. You won't see a notable difference when calling "date" unless you are going to run this command 10.000 per second - but then you are doing something wrong anyway. This discussion very much reminds me to the misbelief that some Gentoo users have that building every package from source with -mnative will have a huge impact on performance. gcc is already generating code which is fast enough on all targets for a given -m value that there is virtually no gain over pre-compiled packages - except for packages like the aforementioned ATLAS. Adrian > [1] https://software.intel.com/en-us/node/523141 -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Please upgrade your machines to sparc64
From: John Paul Adrian GlaubitzDate: Thu, 23 Jun 2016 10:30:14 +0200 > Thus, I don't think any of the objections brought up against the > sparc64 port are valid. Neither is sparc64 64-bit only nor does > anyone anyhow prevent you in Debian to mix packages from different > architectures. In fact, Debian has by far the most flexible approach > to resolve the 32-bit/64-bit problem by providing a generic approach > for mixing libraries of different architectures. I think what irks people the most about what happened, is that the choosen a path is not the most optimal situation for the target platform. The most desirable would have been to build the bulk of userland binaries as 32-bit with v8+ extensions (perhaps even with -mcpu=xxx for some v9 cpu), and then for the specific packages that need it, build 64-bit. And I would assume that would be perhaps binutils and perhaps gcc and GIT. Yes, the 64-bit packages for everything should exist in the repository and be built, but the default install should not have everything 64-bit.
Re: Please upgrade your machines to sparc64
On 06/23/2016 07:54 AM, Alex McWhirter wrote: > I spend most of my time working on pure 64 bit sparc linux. simply because > that's where all the work is currently being done. That being said there are > noticeable speed improvements with some applications being 32 bit. Where did I say that it is impossible to run 32-bit applications? I never claimed that! > As far as I know Debian doesn't really have a way of managing something like > that.Sure you can compile everything both 64 and 32 bit and install whichever > you > want, but there's no way to really say one package should always be 32 bit > while another should always be 64 bit. Even if that did exist sparc is the > only > architecture I'm aware of that would really benefit from it. Except that Debian has the best mechanism to resolve that which is called Multi-Arch. You can install libraries and binaries of *any* architecture onto *any* machine. In fact, I am doing that to cross-compile things like GHC, see: > https://wiki.debian.org/DebianPorts/BootstrappingGHC > Gentoo also suffers from the same issue although its not as bad onsidering > you can switch ABI's on the fly. Debian isn't suffering from that. Your information is simply wrong. > My unofficial Gentoo ports support multilib for people wanting the best of > both worlds. But making it a seemless experience providing the best > performance based > on each applications needs is something that would take a ton of work. It may > not even be possible with the current packaging system. Multilib alone is an outdated and insufficient concept and the reason why we long had ugly solutions like ia32-libs in Debian which carried 32-bit versions of important libraries repackaged as 64-bit packages. These days, this has become completely redundant since you can just directly install i386 packages on an amd64 system if you need 32-bit support on x86_64, for example. However, it doesn't end there. You can even go further and install i386 packages on a ppc64el machine and run them seemlessly there through qemu-user. Although we are currently missing up-to-date 32-bit sparc packages which you could install on sparc64 via MultiArch (unless you want to use the old ones), there is nothing that stops you from setting up a small mini-dinstall server, set up an sbuild schroot for sparc and build custom packages for sparc instead of sparc64. Thanks to the Debian rebootstrap project [1], we are constantly making sure that bootstrapping sparc on Debian will still be possible if required. The project is still under development, but it's already possible to just cross- bootstrap sparc with current packages on any host architecture. Thus, I don't think any of the objections brought up against the sparc64 port are valid. Neither is sparc64 64-bit only nor does anyone anyhow prevent you in Debian to mix packages from different architectures. In fact, Debian has by far the most flexible approach to resolve the 32-bit/64-bit problem by providing a generic approach for mixing libraries of different architectures. Adrian > [1] https://jenkins.debian.net/view/rebootstrap/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Please upgrade your machines to sparc64
Hi, On Wed, Jun 22, 2016 at 09:23:40PM +0200, John Paul Adrian Glaubitz wrote: > That won't change the fact that the majority of work is now happening on > sparc64. I don't think there is a realistic chance of getting most projects > spending much work on the 32-bit code since the focus is on new hardware. > > Either way, Debian sparc (32-bit) is completely unsupported these days > and no longer receiving any security updates. So, anyone should either > use Gentoo or switch over to Debian sparc64. Or compile and maintain your own 32-bit userspace (like I do). For the stuff I need, upstream projects have no issues with 32-bit. A.
Re: Please upgrade your machines to sparc64
From: John Paul Adrian GlaubitzDate: Wed, 22 Jun 2016 21:23:40 +0200 > Alas, I haven't done any detailed benchmarking yet. Too bad, since that's where all the problems will be. Even just doing a kernel build or a gcc bootstrap, you'll see it. And that effects the people like me who you expect to work on bug fixes. Frankly, I'm leaving all of my sparc64 machines, yes all of them, running the unsupported 32-bit userland and will simply live without upgrades and support. That's how important this is to me.
Re: Please upgrade your machines to sparc64
On 06/22/2016 09:46 PM, David Miller wrote: > Frankly, I'm leaving all of my sparc64 machines, yes all of > them, running the unsupported 32-bit userland and will simply > live without upgrades and support. > > That's how important this is to me. I'm not arguing with you that 32-bit code is faster than comparable 64-bit code, it absolutely is. Heck, even Intel realized that a few years ago and they created the x32 ABI [1]. It didn't help though as x32 is rather unpopular among users and developers. We have a handful of users of the port in Debian which I also help to maintain, by the way. And it's not like that people have not run into memory issues when using a 32-bit process address space. 4 GiB can be easily eaten up when building something like Firefox with link-time optimization enabled, so I don't think we have a viable alternative to sparc64 in the long term. Thanks, Adrian > [1] https://en.wikipedia.org/wiki/X32_ABI -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: Please upgrade your machines to sparc64
On 06/22/2016 09:13 PM, David Miller wrote: > From: chase rayfield> Date: Tue, 21 Jun 2016 19:20:59 -0400 > >> How well maintained is the Debian Sparc port these days and what is >> the reason for forcing upgrades to 64bit userland? >> >> Sparcv8+ 32bit code is faster as far as I know in most cases even on >> new Sparcs due to memory overhead for 64bit instructions > > +1000 That won't change the fact that the majority of work is now happening on sparc64. I don't think there is a realistic chance of getting most projects spending much work on the 32-bit code since the focus is on new hardware. Either way, Debian sparc (32-bit) is completely unsupported these days and no longer receiving any security updates. So, anyone should either use Gentoo or switch over to Debian sparc64. So far I haven't seen any issues with the sparc64 port, even on my old Sun Blade 100. Alas, I haven't done any detailed benchmarking yet. Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Please upgrade your machines to sparc64
Hello! According to to Debian's popularity contest page [1], there are still 82 machines reporting to be running Debian's old, unsupported sparc port (32-bit userland, 64-bit kernel). Since popcon only reports machines where the users decided to opt-in, the number of unreported sparc installations will most certainly be higher. I would like to ask anyone still running the old sparc port to reinstall their machines using the sparc64 NETINST installation image [2]. I have just done that yesterday on a SPARC T200 server and it was very easy when you keep a few things in mind: * when setting up the partitions, create a small (~1 GiB) boot partition which is formatted with ext3 and mounted /boot; this is required for SILO to work reliably and find the installed kernels * when prompted to enter mirror data, use the following: - mirror: http://ftp.ports.debian.org - directory: /debian-ports/ although you won't be able to install any packages during installation anyway due to the missing Debian Ports signing key (see next point), you should still already set up the mirror data here as it will be used to configure your /etc/apt/sources.list for the installed system * ignore the error message about software packages being unable to be installed, just skip this step and you will be fine; you can install additional packages easily after rebooting the machine with the installed system * after skipping the software installation step, just let debian-installer finish the installation by installation SILO and completing the remaining tasks * after the machine has reset and is about to boot the installed system, boot the machine with "Linux console=ttyS0,9600,8n1" where "Linux" is the name of the configuration in SILO to be booted (defaults to "Linux" - view available configurations by pressing ) and console=ttyS0,9600,8n1 configures the serial console which is disabled by default currently (I will look into changing this in the future) After system has rebooted, you should be able to log in using the root login you created during installation. Before you will be able to install packages, you need to install the signing key for Debian Ports manually: # gpg --keyserver pgp.mit.edu --recv-keys 705A2CE1 # gpg --export 705A2CE1 --armor | apt-key add - # apt-get update After this, your system should be ready to use and you can upgrade with: # apt-get update && apt-get upgrade When dist-upgrading, *always* read what APT is going to do before hitting and in case some important packages would be deleted, press to cancel. This issue usually resolves after a certain time when the buildds have caught up with building new packages. # apt-get dist-upgrade >>> Read the warnings about potential packages being removed <<< Finally, you should install the popularity-contest package to help the popularity of the sparc64 port: # apt-get install popularity-contest The more people are running the sparc64 port of Debian, the easier it will be for us to convince the release team to make sparc64 an official Debian port! Thanks, Adrian > [1] http://popcon.debian.org/ > [2] > https://people.debian.org/~glaubitz/debian-cd/2016-05-04/debian-9.0-sparc64-NETINST-1.iso -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913