Das 32-Bit-Ende ist "nahe"?!

[EinSteiGer]

Wertes Forum,

ich melde mich mit Blick auf die folgenden Einschätzung im Post von Blackbox (memberlist.php?mode=viewprofile&u=24642) hier im Forum unter viewtopic.php?f=29&t=176270#p1229023:

In debian 10 32 bit sind aktuelle Versionen von Firefox und Chromium in 32 bit dabei.

Die 32 Bit Versionen von Debian werden sicherlich nur noch eine begrenzte Zeit zur Verfügung stehen, wenn man sich anschaut, wie andere Distributionen die bereits ihren eigenen 32 Bit Pfad eingestellt haben, oder dies in absehbarer Zeit planen.

Kannst sogar in beiden einen aktuellen Adblocker installieren.

Das ist richtig.

Dein 32 Bit Notebook musst du also nicht entsorgen, stattdessen kannst du von Stretch auf Buster aktualisieren.

Ich würde schreiben noch nicht entsorgen.

Meine Fragen lautet ganz konkret:
[*]Wie/wann seht ihr das Ende der 32-Bit Unterstützung kommen?
[*]Was können sinnvolle Alternativen zu Debian sein, wenn es soweit ist?

Ich interessiere mich für ernst gemeinte Beiträge gerne auch kritische. Die "Pech-gehabt"-Fraktion (vgl. viewtopic.php?f=28&t=176285#p1229063) möchte ich hiermit bitten sich zu enthalten.

Mit freundlichen Grüßen

[cronoik]

Wie/wann seht ihr das Ende der 32-Bit Unterstützung kommen?

Da musst du dir erst einmal weniger Sorgen machen. Debian moechte das Universal Operating System sein und bietet aktuell auch zig Architekturen an die weniger genutzt werden als i386. Selbst wenn mal ernsthaft darueber diskutiert wird, dann wird da genuegend Zeit eingeplant werden. Ich schaetze das mindestens zu dem Zeitpunkt das gueltige stable und das nachfolgende stable nach einer Entscheidung gegen i386 noch dieses unterstuetzen.

[MSfree]

[*]Wie/wann seht ihr das Ende der 32-Bit Unterstützung kommen?

Die großen Linuxdistributionen haben jetzt schon keine 32Bit Unterstützung mehr.
SuSE hat 2017 32Bit eingestellt
Ubuntu hat schon länger keine 32Bit Version mehr und der 32Bit Support für Programme ( also 32Bit Programme unter 64Bit Linux) wurde letztes Jahr abgekündigt
Redhat ist auch schon lange weg von 32Bit

Debian ist die letzte 32Bit-Burg, fragt sich, wie lange noch.

[*]Was können sinnvolle Alternativen zu Debian sein, wenn es soweit ist?

Es wird keine Alternative geben, das muß man so klar sagen. Natürlich könntest du dir Linux komplett aus dem Source Code in 32Bit selbst bauen, aber auch das wird früher oder später scheitern, weil der Sourcecode irgendwann nicht mehr unter 32Bit kompiliert.

Die "Pech-gehabt"-Fraktion (vgl. viewtopic.php?f=28&t=176285#p1229063) möchte ich hiermit bitten sich zu enthalten.

Pech gehabt.

[hikaru]

[*]Wie/wann seht ihr das Ende der 32-Bit Unterstützung kommen?

"32 Bit" (x86_32) bedeutet momentan unter Debian, dass eine i686-CPU vorausgesetzt wird. Das entspricht einem Pentium I Pro oder einem AMD K7.
Bis einschließlich Wheezy hatte Debian noch eine gut funktionierende i486-Unterstützung.* In Jessie hat man dann auf i586 als Minimum erhöht, was aber nur eingeschränkt stabil war, da der Build auf i686/amd64 lief und dabei unbemerkt i686-Instruktionen eingebaut wurden, die nur auffielen, wenn man tatsächlich versucht hat ein davon betroffenes Programm auf einer i586-CPU auszuführen. Soweit ich weiß hat man sich erst dazu entschlossen, i586 mit Stretch fallenzulassen als dieses Problem bekannt wurde.

Ich würde ein ähnlches Vorgehen beim Fallenlassen von x86_32 erwarten, allerdings mit höheren Hürden. x86_64 (amd64) ist letztendlich eine Erweiterung von x86_32. Man müsste mal schauen, was die Unterschiede der Befehlssätze im Detail sind. Ich glaube jenseits der reinen Speicherbandbreite gibt es noch weitere Unterschiede, z.B. bei den SSE-Versionen.
Ich gehe davon aus, dass Debian x86_32 erst fallenlässt, wenn bestimmte "Blockbuster"-Software (Firefox UND Chromium, Multimedia, oder wichtige Toolkits) selbst nicht mehr x86_32-kompatibel ist. Für Bullseye sehe ich da keine Gefahr und auch für Debian 12 rechne ich nicht damit. Danach müsste man mal schauen. Bis dahin sind aber auch die letzten x86_32-Rechner (die frühen Atom-Netbooks von 2008/09) vermutlich nicht mehr alltagstauglich.

[*]Was können sinnvolle Alternativen zu Debian sein, wenn es soweit ist?

Wenn Debian x86_32 fallenlässt, dann werden alle anderen schon längst das Licht ausgemacht haben. Vielleicht wird man Gentoo noch für die Architektur bauen können und das eine oder andere BSD (v.A. NetBSD?) wird vielleicht auch noch jenseits von Debian x86_32 unterstützen. Aber auch das wird nur akademisch sein, weil kaum noch Anwendersoftware sinnvoll zu betreiben sein wird.


*) Um ehrlich zu sein weiß ich nicht, wie gut das wirklch auf i486 lief, aber auf i586 lief es problemlos.

[jph]

Da nahezu jede Hardware, die in den letzten zehn+ Jahren verkauft wurde, 64-Bit-fähig ist, sprechen wir beim möglichen Wegfall der Unterstützung für i686 in einigen Jahren von musealer Hardware. Damit willst du ernsthaft einen Desktop betreiben, um bspw. den erwähnten Chromium zu betreiben? Ernsthaft: die einzig sinnvolle Alternative ist, neue Hardware zu kaufen.

[Meillo]

Nur nebenbei erwaehnt: Mein neuester Computer ist derzeit 14 Jahre alt. Daran, dass alle meine Rechner inzwischen museal und folglich wie mir scheint irrelevant geworden sind, muss ich mich wohl langsam gewoehnen.

Der einzige Grund der mich zu neuer Hardware draengt ist der riesige Leistungshunger des modernen Webs, fuer Schnickschnack den ich nicht brauche, ich aber auch nicht mehr abschalten kann, weil Websites ohne JS heutzutage nicht mehr funktionsfaehig sind. ... andererseits surfe ich seit zwei Monaten eigentlich ganz gut ausschliesslich mit w3m. Solange das DFDE und die Wikipedia noch ohne JS funktionieren bin ich in der Online-Welt weiterhin lebensfaehig ... aber ich schweife ab.

Ich wollte das nur mal als Gegensatz in den Raum stellen. Es geht auch ohne staendig neue Hardware, Rohstoffverbrauch, Elektroschrott ... Ebenso geht's aber auch ohne Upgrades auf neue Releases ... und darum hat das alles dann letztlich gar nichts mit diesem Thread zu tun.

*SCNR*

[Radfahrer]

Ich verstehe den 'TE. Ständig dieser neumodische Schnickschnack...
Mich nervt es z.B. total, dass es keine einzige Linuxdistri gibt, die auf meinem Atari 400 anständig läuft. Was soll das? Ich kann doch nicht ständig neue Rechner kaufen. Bin ich Krösus, oder was?

[jph]

Der einzige Grund der mich zu neuer Hardware draengt ist der riesige Leistungshunger des modernen Webs, fuer Schnickschnack den ich nicht brauche, ich aber auch nicht mehr abschalten kann, weil Websites ohne JS heutzutage nicht mehr funktionsfaehig sind. ... andererseits surfe ich seit zwei Monaten eigentlich ganz gut ausschliesslich mit w3m. Solange das DFDE und die Wikipedia noch ohne JS funktionieren bin ich in der Online-Welt weiterhin lebensfaehig ... aber ich schweife ab.

Nein, du schweifst nicht ab. Deine Hardware bzw. die des TE funktioniert noch, nähert sich aber dem Limit, weil sich die Anforderungen laufend weiterentwickeln. Wenn man diese Entwicklung in die Zukunft fortschreibt, wird irgendwann der Punkt erreicht, an dem die Hardware die Anforderungen nicht mehr erfüllen kann und ersetzt werden muss.

Meine Meinung – und da sind wir möglicherweise unterschiedlicher Auffassung – ist, dass dieser Punkt für 32-Bit-Hardware lange erreicht bzw. überschritten sein wird, wenn der 32-Bit-Support wegfällt. Abgeleitet aus der Tatsache, dass reine 32-Bit-Hardware schon lange nicht mehr im Desktop-Segment verkauft wird.

Selbstverständlich sind lange Nutzungsdauern von Hardware aus verschiedenen Gründen wünschenswert, aber darum ging es dem TE nicht.

[s_fischer]

Da würde ich mir wenig Sorgen machen und abwarten was von offizieller Seite angekündigt wird. Beim x32 ist ja noch zu unterscheiden, ob der 32er Kernel mit PAE gebaut wurde, oder nicht.

Um mal beim Beispiel SuSe zu bleiben, beim Enterprise ist keine 32er mehr vorhanden, wie @MSfree schon geschrieben hat. Auch bei OpenSuse Leap ist x32 rausgeflogen. Aber beim RR Tumbleweed wird noch i586 angeboten.
https://software.opensuse.org/distributions/tumbleweed

Ich habe die mal testweise installiert, läuft ganz flockig. Man muss sich da nur an das Paketsystem mit Zypper gewöhnen.

[wanne]

Redhat ist auch schon lange weg von 32Bit

Nein. Leider nicht. Du bekommst deine Hardware nicht mehr zertifiziert. Aber die Systeme, die seit 20 Jahren laufen und wirklich mal abgeschaltet werden sollten laufen auch noch mit RHEL 7.

wenn bestimmte "Blockbuster"-Software (Firefox UND Chromium, Multimedia, oder wichtige Toolkits) selbst nicht mehr x86_32-kompatibel ist.

Ich tippe nicht auf Chromium oder toolkits. Das OpenSource-C(++)-Zeug baust du halt für x86 und gut ist. 32Bit Kompatibilität können die nicht auf geben wegen armhf, für da noch mindestens die nächsten 5 Jahre Neugeräte erscheinen. Dickste Kandidaten sind da eher Systemd oder Linux, die Assembler-Teile haben und erstere lieben es mal den Support für irgend was zu droppen. Eventuell auch NSS. Aber dann könnte man Chromium immer noch mit OpenSSL compilieren. Und die droppen garantiert nichts. Für alle sehe ich das nicht so wirklich passieren.
Größeres Problem ist, dass du vermutlich bald in andere Treiberbprobleme Rennst. Das nächste ist, dass die aller meiste x86 Hardware sowieso nicht mehr läuft, weil sie kein SSE2 kann und alles was Video macht damit compiliert ist.

[schorsch_76]

Bei Linux gibt es auch das CIP Projekt. Die halten Software sehr lange am Laufen

viewtopic.php?f=15&t=167338&p=1151149&h ... n#p1151149

[debianuser4782]

Ich hatte einen Acer Aspire 5710Z von meinem Vater mitbekommen, um darauf Debian-Buster-Xfce 32-Bit (i386) zu installieren. Die Hardwaredaten sind:

-Intel pentium dual-core processor T2080 (1.73 GHz, 533 FSB, 1 MB L2 cache)
-Intel Graphics Media Accelerator 950 (auch GMA 950 genannt)
-2GB DDR2
-15.4* WXGA Acer CrystalBrite LCD (8ms/220-nit)
-160GB HDD (ausgetauscht durch eine 128GB SSD von Intenso)
-DVD-Super Multi double layer
-802.11 b/g WLAN

Nach dem Austausch eines defekten 1GB RAM-Riegels (4 Euro bei amazon, davon 3 € Versandkosten) funktionierte die Installation gut und Xfce läuft mit den 2 GB auch flüssig. (Mit 1GB lief auch alles sehr gut, selbst mit Firefox). Hochauflösende Videos ließen sich abspielen, solange man das Videofenster klein hielt.
Gnome hatte ich auch versuchsweise installiert. Dort wurde die GMA 950 automatisch erkannt und installiert. Nur die 3D-Programme ruckelten etwas zu arg, weswegen sich aus der Installation der GMA950 über Gnome kein Vorteil ziehen ließ.
Solange man keine 3D Anwendungen benötigt, sind diese Geräte eigentlich noch gut zu gebrauchen und sie mit moderner Software wieder zum Leben zu erwecken, bereitet viel Freude.

[waldbaer59]

Ich bin gerade dabei, einen HP Thin Client (T5470) aufzubauen. Das war auch der Grund warum ich bei Debian aufgeschlagen bin . Die Installation von Buster war kein Problem; die Performance ist überraschend gut.
Es wäre schön, wenn solche Hardware noch als Komponente im Netzwerk einige Dienste leisten könnte.

VLG
Stephan

[MSfree]

Ich bin gerade dabei, einen HP Thin Client (T5470) aufzubauen.

Das ist ein Core2-Duo, und somit eine 64Bit-CPU.

Thema verfehlt, würde ich sagen.

[waldbaer59]

Dann könnte ich andernfalls was in der Geräte Bezeichnung durcheinander gebracht haben. Denn meinen 64-Bit Installer für Arch Linux wollte er nicht starten: und zwar wegen der 64 Bit...

*schulterzuck*

Es ist ein Atom N280 Prozessor drin, zwei Kerne (oder wenigstens zwei Threads), aber keine 64 Bit.
Ach, jetzt habe ich es gefunden. Die Kiste nennt sich HP T5740. Zahlendreher, der einen beim Nachschlagen auf die falsche Fährte bringt.

Sorry dafür....

[hikaru]

wenn bestimmte "Blockbuster"-Software (Firefox UND Chromium, Multimedia, oder wichtige Toolkits) selbst nicht mehr x86_32-kompatibel ist.

Ich tippe nicht auf Chromium oder toolkits. Das OpenSource-C(++)-Zeug baust du halt für x86 und gut ist. 32Bit Kompatibilität können die nicht auf geben wegen armhf, für da noch mindestens die nächsten 5 Jahre Neugeräte erscheinen.

Ich habe nicht umsonst sauber zwischen "x86_32" und "32bit" unterschieden. x86_32 wird vermutlich nicht wegen der Busbandbreite unbenutzbar werden, sondern weil hier im Vergleich zu x86_64 Instruktionen fehlen, die irgendwann von "moderner" Software hart vorausgesetzt werden. Als möglichen Kandidaten hatte ich die SSE-Familie angeführt.
Arm hingegen ist ein völlig anderes Ökosystem. Was die Busbandbreite angeht, mögen x86_32 und "arm32"* vergleichbar sein. Aber hier enden die Gemeinsamkeiten auch schon. Anzunehmen, dass x86_32 so lange funktionieren wird, wie noch "arm32" unterstützt wird, ist ein Trugschluss.

*) Hier als Sammelbegriff für alles unterhalb von "arm64" zu verstehen

[wanne]

Ich hatte von OpenSource C++ Programmen geschieben. Die können kein SSE vorassetzen. Ich sag dem Compiler halt das ich das nicht habe und der benutzt das nicht. Aus C(++) sicht ist armhf und x86 das selbe. So lange der Code auf den arms läuft tut er das auch auf x86. Problematisch sind nur Programme für die es keinen (vollständigen) Sorce gibt.

[pferdefreund]

Ich sehe das genauso wie einige andere hier. Warum alte voll funktionsfähige Hardware entsorgen ? Mein IBM R52 rennt problemlos - momentan noch auf Debian 9. Alles funktioniert inklusive Videos ohne Ruckeln. Oberfläche ist der schlanke icewm, Browser Palemoon. Das Ding hat eine 1,8 Ghz Centrino-CPU und mittlerweile wohl su um die 15 Jahre auf dem Buckel. Einzige "Reparatur" bisher war eine neue BIOS-Batterie. Ich werde das Teil nutzen, solange es irgendwie geht. Ist einfach zuverlässig wie ein alter Benz Diesel. Ja, mit den Autos halte ich es genauso. So lange fahren, bis es sich wirklich nicht mehr lohnt, was reinzustecken. Waren bei den letzten 2 mal 15 und dann 17 Jahre. Mal sehen, wie lange der jetzige hält - hat jetzt auch schon 10 Jahre auf dem Buckel. Im Notfall dann halt apt-get source und Konsorten, und so möglich, selber bauen. Bin ja ab Juli in Rente und dann hat man Zeit für sowas.

[MSfree]

Ich hatte von OpenSource C++ Programmen geschieben. Die können kein SSE vorassetzen.

Für SSE gibt es spezielle Funktionsaufrufe oder es findet im Assembler statt. Beide Fälle sind aber ausschließlich auf Intel/AMD lauffähig. ARM, MIPS, PPC... kennen SSE nicht, die haben andere zu SSE inkompatible Vektorerweiterungen (was man aber teilweise wieder über den Compiler hinbiegen kann).

So lange der Code auf den arms läuft tut er das auch auf x86.

Jein. Solange man keine speziellen Vektorerweiterungen nutzt, ist das richtig. Aber auch ARM geht in Richtung 64Bit, Apple führt schon seit IOS12 keine 32Bit Apps mehr aus. Auch Raspi-2 und neuer sind bereits 64Bit CPUs, nur, daß das von Raspbian noch nicht genutzt wird, weil man noch kompatibel zum 32Bit Raspi-Zero(W) sein will und wohl keine zwei Distributionen pflegen will.

[hikaru]

Ich hatte von OpenSource C++ Programmen geschieben.

Du hast dich auf meine Aussage bezogen, dass bestimmte Software sich irgendwann nicht mehr unter x86_32 compilieren lassen wird. Es ist reichlich naiv anzunehmen, dass große Projekte wie "Full-Feature-Browser" mit all ihren Abhängigkeiten, welche eigene Build-Optionen setzen, sich von Dritten so durchschauen lassen, dass dort architekturspezifische Quirks angebracht werden können.
Als Beispiel verweise ich mal auf willys letzten Waterfox-Thread, wo es nicht mal um Architektur, sondern "nur" um Glibc-Funktionen ging. [1]
Alternativ kannst du als Übungsaufgabe gern mal versuchen, einen aktuellen Chromium auf i586 lauffähig zu machen!

[1] viewtopic.php?f=29&t=176204

[wanne]

Für SSE gibt es spezielle Funktionsaufrufe oder es findet im Assembler statt. Beide Fälle sind aber ausschließlich auf Intel/AMD lauffähig. ARM, MIPS, PPC... kennen SSE nicht, die haben andere zu SSE inkompatible Vektorerweiterungen.

Genau meine Aussage: Solange die Software auf arm bauen will tut sie das auch auf x86. So hält arm x86 am laufen.

Für SSE gibt es spezielle Funktionsaufrufe oder es findet im Assembler statt.

Ja: Wie gesagt bei Assembler (ob inline oder direkt) ist das ein Problem. Bei C++ nicht. Gibt aber nicht viele Programme die Assembler Anteile haben. Defakto ist das halt der Kernel und ein paar Crypo-Libs.

Aber auch ARM geht in Richtung 64Bit, Apple führt schon seit IOS12 keine 32Bit Apps mehr aus. Auch Raspi-2 und neuer sind bereits 64Bit CPUs, nur, daß das von Raspbian noch nicht genutzt wird, weil man noch kompatibel zum 32Bit Raspi-Zero(W) sein will und wohl keine zwei Distributionen pflegen will.

Ja. Glaube aber nicht, dass sich das in den nächsten 5 Jahren auf dem Low-End Markt durchsetzt. Und dann gibt es noch ne weile Altgeräte

wo es nicht mal um Architektur, sondern "nur" um Glibc-Funktionen ging.

Nein. Das ist nicht "nur" sondern eine völlig andere Größenordnung von Problem. Ne zusätzliche api bereitstellen kann keine Distribution. Ich kenne genau eine Distribution, die verschiedene inkompatible libcs bereitstellt und das ist OpenWRT. Aber Debian kann jetzt schon problemlos 10 Architekturen bereitstellen. Die tun sich mit einer mehr oder weniger nicht schwer. Die Maintainer müssen die Übersicht über die Architekturspezifischen Quirks haben. Sonst tut das nicht. Insbesondere weil sich die Entwickler selbst wenig gedanken darüber machen, wie ihr Zeug auf mipsel compiliert. Da gehört der FF ausdrücklich dazu der bis vor kurzem offizell sogar ausschließlich x86 kannte. (Und gar kein x86_64. In Debian war das natürlich trotzdem drin. So wird das auch in die andere Richtung luafen.) Wenn du den Mozilla Leuten mit mips kommst fragen sie dich was das ist. Das ist btw. auch der unterschied zu vielen anderen Distros die eh nur x86_64 und x86 machen. Für die ist es eine Erleichterung, wenn sie sich darum nicht mehr um unterschiedliche Architekturen kümmern müssen.

[wanne]

Hier die Open Source-Debian Pakete, die Assembler enthalten:

Sind laut Wikidata insgesamt 18¹:

Code: Alles auswählen

Aircrack-ng
american fuzzy lop
Arduino
GMP
GNU GRUB
Go
libvpx
LILO
Linux kernel
Memtest86+
Mesa
mpg123
Nettle
OpenSSL
SYSLINUX
Tiny C Compiler
UPX
x264

Kann sein dass die was vergessen haben. Aber das sind drein Hand voll Andwendungen. Die aller meisten (OpenSSL, GMP..) funktionieren expizit auch ohne die Assembler teile und es ist nur eine Option zum Beschleunigen. Gefährlich weil wirklich nötig ist halt: libvpx, Mesa, mpg123 und eventuell Go damit sind wir bei 4 relevanten Paketen. Für alles andere gibt es dann im Zweifelsfall das eine unwichtige Paket nicht. Für alle anderen Pakete hast du das Problem nicht.

[¹] https://query.wikidata.org/#SELECT%20DI ... 0%7D%0A%7D

[nudgegoonies]

Die i386 Platform ist auch beim Linux Kernel selbst nicht die gepflegteste wie ein Kernel-Entwickler anmerkt:
https://www.heise.de/ct/artikel/Linux-5 ... ml?seite=8
Ich vermute aber, dass uns i386 im Kernel wegen Embedded/Industrie, IOT, etc. noch extrem lange erhalten bleibt.

Tatsächlich hat mein Mini-Server den letzten ATOM Prozessor, der kein amd64 kann. Aber das wichtigste Argument pro i386 in Debian für mich persönlich ist WINE. Ohne Wine müsste ich Multiarch nicht mal aktivieren. Ich habe so viele alte 32 Bit Windows Spiele, die ich nicht missen möchte. Da gab es auch bei Ubuntu lange Diskussionen, als sie die i386 Architektur rauswerfen wollten. Den Heise Newsticker Eintrag dazu finde ich leider nicht. Aber ich meine der Tenor war, dass man alle für WINE benötigten 32 Bit Bibliotheken weiter bauen könnte. Ohne ein 32 Bit WINE und die 32 Bit Bibliotheken von denen es abhängt kann man nun mal wirklich nur noch 64 Bit Windows Programme laufen lassen. Und da habe ich auch diverse, wo der Installer als 32 Bit Binary daherkommt obwohl er ein 64 Bit Programm installiert.

[MSfree]

Ich vermute aber, dass uns i386 im Kernel wegen Embedded/Industrie, IOT, etc. noch extrem lange erhalten bleibt.

Nein. Bitte nicht alle 32Bit-CPUs in einen Topf werfen. Embedded ist nur in den seltensten Fällen i386. Intels Quark-Plattform ist z.B. gescheitert.

Es gibt im Kernel Code, der CPU-spezifisch ist. Wenn im 32Bit-ARM-Code ein Fehler behoben wird, ist der noch lange nicht aus dem i386-Code raus. Und das ist es, was der Kernelentwickler gemeint hat, der i386-Code ist teilweise vernachlässigt, während ARM-Code in deutlich besserem Zustand ist.

[wanne]

Es gibt im Kernel Code, der CPU-spezifisch ist. Wenn im 32Bit-ARM-Code ein Fehler behoben wird, ist der noch lange nicht aus dem i386-Code raus. Und das ist es, was der Kernelentwickler gemeint hat, der i386-Code ist teilweise vernachlässigt, während ARM-Code in deutlich besserem Zustand ist.

Ja. Am Ende nehme ich stark an, dass Debian genau so lange supportet wie der Kernel es tut. Wenn die aufhören kann Debian auch nichts mehr machen. Leider verdanken wir ja systemd, dass Hurd und kFreeBSD rausgeflogen sind. Zumindest ersteres wird vermutlich noch auf Ewigkeiten x86 supporten. Eventuell bringt devuan ja bald Hurd support.