Simon Lees wrote:

On 02/08/17 22:45, Richard Biener wrote:

...

On Wed, 2 Aug 2017, Mari Donkers wrote:

...

To quote https://en.opensuse.org/Lifetime : "openSUSE Tumbleweed is a rolling release which has a lifetime of 'forever', assuming you are running the latest updated packages."

What is the roadmap concerning Tumbleweed for Intel 32-bit (i586) architecture? Will it supported into the dim and distant future?

Or will it maybe turn into a repository providing multilib stuff for x86_64 only? A first step would be to raise the minimum architecture level to that of x86_64, a second step would be to drop support for running a 32bit kernel (but still allow to install a full 32bit userland).

How many people really care for running _Tumbleweed_ on ancient (<= i586) hardware?

Well a openSUSE way of looking at it is, while it works and it passes QA there is no point in dropping it. Once it stops working, if no one steps into fix it (like what happened with Leap) then there is very good reason to drop it.

That pretty much describes the situation at the moment. So far TW was close to drop i586 several times already but then someone managed to fix it last minute again. In case i586 support needs to be dropped indeed at some point there would still be the option for someone to maintain it in a ports project at different pace. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Aug 02, 2017 at 10:54:25AM -0400, futureboy@delorean.net wrote:

Not that my vote really carries any weight at all but I am working on a project for a 32bit x86 Dell Tablet

Does the tablet really have a 32-bit CPU? There are many tablets which are shipped with 32-bit Windows but have 64-bit CPU. They also have 32-bit UEFI which prevents you from installing 64-bit openSUSE the standard way (our installer cannot handle it - or at least it couldn't last time I checked) but the system can be made to work with some effort. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Am 02.08.2017 um 15:15 schrieb Richard Biener:

How many people really care for running _Tumbleweed_ on ancient (<= i586) hardware?

It is the only openSUSE option left for non-64bit x86 hardware. -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Wed, Aug 02, 2017 at 03:15:22PM +0200, Richard Biener wrote:

How many people really care for running _Tumbleweed_ on ancient (<= i586) hardware?

I volunteer one day a week at a non-profit organization in Kansas City, whose mission is to refurbish donated computers and sell then at low price to low-income people. Any machines that are received with a dual-core CPU are outfitted with Windows 10, but systems weaker than our cutoff have Leap 42.3 put on them and are given free to the poorest people. We recently received 4 Dell D820 laptops in extremely good condition. The original plan was to put 32-bit Windows on them; however, they only came with 2 GB RAM, and the machines are very picky about which RAM will work. After quite a bit of effort, our manager gave up. As the Linux expert in the shop, I was charged with finding a 32-bit version of Linux for them. I really hate to even consider a rolling release for machines going to users with little sophistication, but I see few options. As the recipients will likely have only Windows experience. I need something on the desktop that looks like a "Start" button. Using a VirtualBox VM for testing, the only workable candidate is TW with an LXDE desktop. There are really people that need 32-bit systems. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 08/02/2017 07:47 PM, Cristian Rodríguez wrote:

El 02-08-2017 a las 17:07, Larry Finger escribió:

...

Dell D820

Those are intel x86_64 "Merom" CPUs.. did you test it with an x86_64 version ? I know that with 2GB RAM some things may run poorly..but so does Windows.

If you try to boot any 64-bit medium, you get the error message telling you to use a 32-bit system. Yes, these machines may not work well with 2 GB RAM, but they will work better under Linux than Windows. Larry -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thursday, 3 August 2017 3:29 Larry Finger wrote:

On 08/02/2017 07:47 PM, Cristian Rodríguez wrote:

...

El 02-08-2017 a las 17:07, Larry Finger escribió:

...

Dell D820

Those are intel x86_64 "Merom" CPUs.. did you test it with an x86_64 version ? I know that with 2GB RAM some things may run poorly..but so does Windows.

If you try to boot any 64-bit medium, you get the error message telling you to use a 32-bit system.

This may be because of 32-bit UEFI (as with the tablets I wrote about yesterday). If they are shipped with 32-bit Windows by the vendor, it's quite likely this problem. Our installer AFAIK doesn't support installation of 64-bit openSUSE on machines with 32-bit UEFI but once you get the system there (e.g. by copying root filesystem from a virtual machine) and set the bootloader up (which may be a bit tricky, I admit), it does work. The support for EFI mixed mode is enabled in 42.3 kernel but I'm not sure if its grub has all necessary patches. If not, you can find grub2 package with them e.g. in home:mkubecek:baytrail OBS project. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thursday, 3 August 2017 10:21 Andrei Borzenkov wrote:

On Thu, Aug 3, 2017 at 9:58 AM, Michal Kubecek wrote:

...

This may be because of 32-bit UEFI (as with the tablets I wrote about yesterday). If they are shipped with 32-bit Windows by the vendor, it's quite likely this problem.

To my best knowledge 32 Windows never supported (and still does not support) EFI. I may be wrong though.

IMHO you are. I have Acer Aspire 10E convertible which was shipped with 32-bit Windows 8.1 and has (32-bit) UEFI. If there was an option to enforce legacy BIOS-style boot, everything would be way easier.

- grub2 i386_efi simply is not available on x86_64; it needs to be either built explicitly or some magic that pulls in 32 bit builds must be used. I wish openSUSE had either actual multiarch support or at least allowed grub2 packages to be noarch; currently it results in error because rpmlint assumes ELF binaries cannot be in noarch

Yes, one thing I had to do was to pick the i586 package for that. But that's easy to fix and if we want to drop i586 architecture one day, this is one of the things we should do.

- perl-Bootloader used to force x86_64_efi on 64 bit, not sure whether it changed with new shell based implementation. If it still does, keying platform selection on EFI arch does not require any explicit grub support.

I don't remember having any problem with that. Grub2 setup regenerates correctly for me on kernel updates. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 03/08/17 17:51, Andrei Borzenkov wrote:

On Thu, Aug 3, 2017 at 9:58 AM, Michal Kubecek wrote:

...

This may be because of 32-bit UEFI (as with the tablets I wrote about yesterday). If they are shipped with 32-bit Windows by the vendor, it's quite likely this problem.

To my best knowledge 32 Windows never supported (and still does not support) EFI. I may be wrong though. ...

...

The support for EFI mixed mode is enabled in 42.3 kernel but I'm not sure if its grub has all necessary patches. If not, you can find grub2 package with them e.g. in home:mkubecek:baytrail OBS project.

I see two problems

- grub2 i386_efi simply is not available on x86_64; it needs to be either built explicitly or some magic that pulls in 32 bit builds must be used. I wish openSUSE had either actual multiarch support or at least allowed grub2 packages to be noarch; currently it results in error because rpmlint assumes ELF binaries cannot be in noarch

If it makes sense and is reasonable you can get rpmlint to ignore the error with a rpmlintrc file, just be sure to clearly document why it exists. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

Am 03.08.2017 um 02:47 schrieb Cristian Rodríguez:

El 02-08-2017 a las 17:07, Larry Finger escribió:

...

Dell D820

Those are intel x86_64 "Merom" CPUs..

Not necessary. D820 was available e.g. with https://ark.intel.com/de/products/27244/Intel-Core-Solo-Processor-T1400-2M-C... -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On 03/08/17 06:37, Larry Finger wrote:

On Wed, Aug 02, 2017 at 03:15:22PM +0200, Richard Biener wrote:

...

How many people really care for running _Tumbleweed_ on ancient (<= i586) hardware?

I volunteer one day a week at a non-profit organization in Kansas City, whose mission is to refurbish donated computers and sell then at low price to low-income people. Any machines that are received with a dual-core CPU are outfitted with Windows 10, but systems weaker than our cutoff have Leap 42.3 put on them and are given free to the poorest people.

We recently received 4 Dell D820 laptops in extremely good condition. The original plan was to put 32-bit Windows on them; however, they only came with 2 GB RAM, and the machines are very picky about which RAM will work. After quite a bit of effort, our manager gave up. As the Linux expert in the shop, I was charged with finding a 32-bit version of Linux for them. I really hate to even consider a rolling release for machines going to users with little sophistication, but I see few options. As the recipients will likely have only Windows experience. I need something on the desktop that looks like a "Start" button. Using a VirtualBox VM for testing, the only workable candidate is TW with an LXDE desktop.

There are really people that need 32-bit systems.

Larry

On tumbleweed you could also consider LXQt which has seen a lot of work over the last few years. 2GB systems for web browsing are starting to get harder though, its not uncommon for my browser to end up using 2GB on its own. There is also the fact that browsers are now starting to look towards dropping i586, I suspect when i586 does get dropped it will more be because several key upstreams have dropped support rather then something we can control. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On Wed, Aug 2, 2017 at 3:15 PM, Richard Biener wrote:

On Wed, 2 Aug 2017, Mari Donkers wrote:

...

To quote https://en.opensuse.org/Lifetime : "openSUSE Tumbleweed is a rolling release which has a lifetime of 'forever', assuming you are running the latest updated packages."

What is the roadmap concerning Tumbleweed for Intel 32-bit (i586) architecture? Will it supported into the dim and distant future?

Or will it maybe turn into a repository providing multilib stuff for x86_64 only? A first step would be to raise the minimum architecture level to that of x86_64, a second step would be to drop support for running a 32bit kernel (but still allow to install a full 32bit userland).

How many people really care for running _Tumbleweed_ on ancient (<= i586) hardware?

We use hardware with proprietary access libraries that are only available as 32-bit. It is not something we have control over. It can be the latest 32-bit processor. Updating the computer is not a problem. It's the data collection hardware that we have to live with. It was a case of a supplier who made a Linux release and then decided not to continue to do so. It involves frame grabber hardware that provides access to a high-speed, high-resolution (and very expensive) laser scanning system (http://www.pavemetrics.com/applications/road-inspection/laser-road-imaging-s...). We have limited customer use. If we ever need to update these systems, we would like to update the OS as well. So we have been considering 32-bit Tumbleweed. They now run openSUSE 12.1 or 12.3. If Tumbleweed decide to drop support for 32-bit, I would hope that the final 32-bit stuff would remain available - if unsupported. This would include all the repositories on OBS. Not just the final install media. That alone makes it possible to work with a discontinued release. I realize this is not a great use case that would make anyone want to work to maintain support. So, simply keeping the final stuff around (don't delete the OBS builds even if they do not do now ones) would really make a difference to me. In fact, I bet that the Tumbleweed source RPMs would suffice. For the release and for the repos in OBS. Just my 2cw. -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Aug 3, 2017 at 8:41 AM, Simon Lees wrote:

It will still be possible to install 32bit applications on 64bit systems like it is currently, have you tried running your application on Leap with the 32bit compatibility libraries installed? Its probably a better solution.

It is a mixed thing. The frame grabber cards are accessed via a kernel driver. Happily, the card manufacturer provides both 32- and 64-bit drivers. So, if I am lucky, the 64-bit drivers may work. The difficulty is that the 32-bit access library to control the sensors connected to the card is compiled against the 32-bit kernel drivers. So I wonder if it could talk to the 64-bit driver without modification. And, of course, I would need to find 64-bit drivers that work with a new kernel but are compatible with the 32-bit drivers that the access library was compiled to use... In fact, I guess I might face the same problem finding a 32-bit driver that works with a new kernel (as supplied in 32-bit Tumbleweed) that also works with the old 32-bit access library. So there are more than 32-/64-bit issues. But you are right. It is a possible solution. Something tells me that we are going to have to keep these customers on their current OS which we will have to continue to support... See the problems that proprietary code causes? -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thu, Aug 3, 2017 at 9:33 AM, Simon Lees wrote:

There are plenty of manufacturing facilities running really old OS's to support there old hardware with old drivers, generally the key is to either not put them on a network or put them on a segregated network with no internet access. At the last company I worked for most of the computers in manufacturing had no internet access and when you wanted to put a new file on or change something you used a flash drive.

The thing is that this computer also runs our software. And our software progresses. We add new features. As one does. Often this results in new library requirements. We have no interest in being stuck at the level of things available 5 or 10 years ago. I suspect that a possible solution is to move the proprietary system to it's own computer, and control it over the network via our own protocol. We have done this before. It does isolate us from these sad facts of life. In fact, we use openSUSE images built with kiwi that allow these computers to boot without an OS. From the OS POV they are diskless and do not change the boot images - only temp stuff in RAM. So they never get corrupt and are easy to set up (after the first one...). Oh the things we do with openSUSE... There is always a solution. A 32-bit Tumbleweed is one of them that creates the smallest disturbance. But there are others. It's what keeps me in a job :) -- Roger Oberholtzer -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

On Thursday, 3 August 2017 8:14 Roger Oberholtzer wrote:

On Wed, Aug 2, 2017 at 3:15 PM, Richard Biener wrote:

...

Or will it maybe turn into a repository providing multilib stuff for x86_64 only? A first step would be to raise the minimum architecture level to that of x86_64, a second step would be to drop support for running a 32bit kernel (but still allow to install a full 32bit userland).

How many people really care for running _Tumbleweed_ on ancient (<= i586) hardware?

We use hardware with proprietary access libraries that are only available as 32-bit. It is not something we have control over. It can be the latest 32-bit processor. Updating the computer is not a problem. It's the data collection hardware that we have to live with.

If it's only a 32-bit _library_ (i.e. not kernel drivers), you shouldn't need a full 32-bit distribution, 32-bit libraries on x86_64 distribution should suffice. Michal Kubeček -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Richard Biener composed on 2017-08-02 15:15 (UTC+0200):

How many people really care for running _Tumbleweed_ on ancient (<= i586) hardware?

I have to think if it wasn't a rolling release that those in timing critical situations and would rather openSUSE than something else would, as summarized here: https://lists.debian.org/debian-user/2017/07/msg00320.html I emailed the author for more details, and got what follows in response: That is probably my best argument on the subject Felix. Generally we build an rtai patched kernel, which is a rather daunting task and use it until its hardware support forces the issue again in 2 or more years. currently, 3 of the 4 cnc machines here are still on the 3.4-9-rtai-686-pae kernel, which has some warts but is generally stable and gives us latencytest results in the 5 to 7 microsecond range. This is not great but is good enough to do software step generation, driving a small machine at useable speeds directly from the parport, in this particular case an atom powered intel D525mw motherboard with 4Gb of dram on it. All other machines here have mesa (or similar, there are other competing brands, usually needing a larger stack of green to buy but with far less responsive support) interfaceing cards installed, which interpose an FPGA based board that does this stepper generation in hardware, and which can, motor voltage effects included, drive the stepper 4 to 8 times faster, because the steppers available speed is highly dependent on a steady stream of pulses so its traveling at a consistent speed. Because steppers stop if something disturbs the step timing for 50 microseconds, and it cannot re-accelerate quick enough when the next step does arrive, they will stall at zero speed until such time as its driver stops it, and the accelerates it again. Needless to say, that stoppage wrecks the part, possible breaking a $20+ dollar cutting tool and generally raising all sorts of blue air in the shop when that happens. We don't need the latest whizbang hardware, but that same latency-test program, running on 64 bit hardware, has IRQ latencies in the 100-500 microseconds (unless the user is using the nvidia supplied drivers, which can expand those results into the hundreds of milliseconds range), restricts the machines top speed from 50 or more inches a minute, to under 10 inches a minute, with 5 to 7 for a safety margin under working loads. So yes, we need a 32 bit linux else it raises the cost of converting a manual machine, or a machine whose controls have died, and the maker is long gone. To illustrate, my latest build has a raspberry pi 3b doing the computing. But it also has a 65 dollar controller card which in turn needs 3 ea filter/surge absorbing cards at $45 each because the FPGA's are killed by I/O voltages above 3.4 volts, and the induced from one wire to the next voltages in a box full of stepper drivers can exceed 30 volts. I wouldn't call the raspi setup 100% usable because of the pi's I/O architecture, it runs the code just fine but drops keyboard events, so I will be investigating the rock64 board when it ships as it claims to not suffer from the I/O problems the raspi's have. But it is running a nearly 70 yo, 1500 lb Sheldon lathe right now. Hopefully the spi support it has will allow us to use the spi driver we have with little or no patching. TBD of course. I know, TL;DR, but thats my 2 cents. Thanks for asking, Felix. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org