cat instructions | wrapper foo
Hoi, Programma foo is een commandline programma voor interactief gebruik. Wel wordt iedere keer hetzelfde met foo gedaan. Dus ik dacht ik zet de instructies in een tekstbestand en voer dat dan aan foo: cat instructions | foo blijkt dat het niet werkt. Foo klaagt dat er geen standaard in is. Ik ben nu opzoek naar een "wrapper" die foo het idee geeft dat dat er wel standaard in is. Dit zou dan werken: cat instructions | wrapper foo Wat is de echte naam van de wrapper? Groeten Geert Stappers -- Silence is hard to parse
Re: Very old hardware...
On Sun 05 Jul 2020 at 23:44:09 (+0200), Thomas Schmitt wrote: > David Wright wrote: > > > > My 650MHz Pentium III (Coppermine) [...] > > consumes ~50mA idling, ~300mA when busy. [...] at 220V > > 11 to 66 Watt. That's unusual for a full size PC of that time. > I knew some which issued 10 Watts already by noise power and could > heat a small sized office room in winter. Sorry, "idling" is probably not the best term—I extracted the line from a spreadsheet of power consumptions for a multitude of different electronics and electrical appliances. For this PC, it means switched on, but with only the NIC waiting for a wakeup call. So the disks, fan and, I assume, the CPU, are not running. The ability to wake it up is not something I currently use on this machine because of its convenient location; though after shutdown, I don't rush to turn off the wall switch. > Google ... > https://en.wikipedia.org/wiki/Pentium_III > 22.41 Watt of TDP. That's about the same as with one 3.5 GHz Xeon core. > But i'd say the Xeon core is about 20 times more powerful (64 vs. 32 bit, > factor 5 of frequency, two hyperthreads). Sure. But my Pentium III's CPU (perhaps not the OP's) is not the issue. Rather, it's the ability of the mobo and box to host several PATA disks. Here for comparison are some figures for a 2013-vintage Dell AiO 3011, which is permanently on at the wall except when big storms threaten. It runs off a dirty great brick supplying, I assume, the usual 19V. These very approximate mA currents are obviously measured on the 110V side: Powering on at wall switch 200 two second surge Power connected, waiting for NIC wakeup 30 Powering on with its switch 350 one second surge Running, at login prompt200-250 Unlocking encrypted /home 500 one second surge Starting X 300 Running X 200-250 Starting firefox300-325 Compiling the linux kernel I no longer do it :) Cheers, David.
Re: Using .XCompose
On Sat, 11 Jul 2020 David Wright wrote: I would attempt to back out of the changes made. Removing/hiding .XCompose is an obvious first step. Yes. '!' marks the spot of nonbreaking spaces that made it into OP's first report of odd behavior, upon testing the white scissors XCompose rule: $ grep "WHITE SCISSORS" d-u_xcompose_2020-07-08.nbsp | tr $'\xc2\xa0' \! : "✄" U2704 # WHITE SCISSORS This message: https://lists.debian.org/msgid-search/620563117.3978825.1594226239...@mail.yahoo.com "Now, things are even more strange. When I press the Caps Lock, a strange character appears. [...]" -- Ce qui est important est rarement urgent et ce qui est urgent est rarement important --Dwight David Eisenhower
Tex characters
David Wright [2020-07-11T09:51:07-05] wrote: > In TeX, you would type in Mr~Wright, because it's considered that Mr > Wright is not the polite way to print a name in a book. I've never > tested whether modern versions of text will handle Mr Wright directly > as input, [...] At least with Xetex and Luatex compilers both tilde (~) and U+00A0 NO-BREAK SPACE can be used as a non-breaking space. There is one difference. Tilde is a stretchable space just like normal word space. U+00A0 is a fixed-width space and more suitable for keeping some closely related parts together. (And let's not forget \, command which is a fixed 1/6 em space.) -- /// Teemu Likonen - .-.. http://www.iki.fi/tlikonen/ // OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450 signature.asc Description: PGP signature
Re: Using .XCompose
On Sat, 11 Jul 2020 davidson wrote: On Fri, 10 Jul 2020 Ajith R wrote: [snip] So, as Zeenan says, there is something fundamentally wrong in my system. I have to find that and correct it or reinstall everything. Is the situation still as you describe here? 8 July 2020 Ajith R to debian-user https://lists.debian.org/msgid-search/620563117.3978825.1594226239...@mail.yahoo.com [snip] If this is still so, we ought to figure out what's going on. To this end, I previously asked for the output of $ xmodmap and $ xmodmap -pk These are, by the way, purely diagnostic command lines. They are requests to print information only. If you issue them as written above, they will alter nothing except (possibly) our state of ignorance. That is, in my ignorant optimism I imagine their output might help somebody make informed, helpful suggestions. While I'm here, I will add to that pair a request for the output from a third, also purely diagnostic: $ setxkbmap -print -- Ce qui est important est rarement urgent et ce qui est urgent est rarement important --Dwight David Eisenhower
Re: Using .XCompose
On Sat 11 Jul 2020 at 08:39:26 (+), davidson wrote: > On Fri, 10 Jul 2020 Ajith R wrote: > > Thanks for your experiment. The fact that it works atleast in some > > applications gives hope. > > […] > > Curious parties (like myself) wishing to understand the orthographic > peculiarities at issue here, might find the following section of the > Wikipedia entry on Malayalam script provides brief, helpful > background: > > https://en.wikipedia.org/wiki/Malayalam_script#Ligatures Naturally, this page concerns itself mainly with how "letters" are written to compose words on the page. But there's a short section at the end about how the "letters" are represented in the computer and, possibly, how they are typed in in order to achieve that internal representation. Again, I can only talk about languages I understand. In English, there's a convention that fi is printed differently from the letters f and i. Similarly, ffi, fl and ffl. However, this modification is performed on output, in accordance with the font being used. "Difficult" is always typed in and stored with the letters f f i. OTOH, although in the early days of computing, the lack of different characters forced people to use 1/2 to represent a half, there's no doubt that ½ exists as a character which can be input and stored as just that: ½. My father would think it odd that computer keyboards (often/usually) don't have that key, because all the typewriters and adding machines from his era did. So it's natural that I should wish to define a sequence of keystrokes that types ½, and that's what I have. It's CapsLock 1 2. It might not work absolutely everywhere, but typically they're going to be places I wouldn't want or need to use it. For example, the getty where I log in (can't), and anywhere where keys aren't reflected, like passwords/phrases (wouldn't). So those examples, fi and ½, illustrate the difference between modification on output and input in English. I can't judge how the OP views this, nor whether they are contravening some conventions in their own computer culture by trying to make their changes. This doesn't even address how a computer responds to a command line written in non-latin script. > The "appropriate geminate glyph" refered to in property (2) above is > illustrated in this table, in the "ligated" row under the column > headed "ṅṅa". > > https://en.wikipedia.org/wiki/Malayalam_script#Common_consonant_ligatures > > > I copied your exact sentences to my compose file. > > > > In Konsole the command cat ~/.XCompose gives the result: > > > > include "%L" > > : "ങ്ങ" # Ajith's auto-geminate rule, (U0D19) => (U0D19) (U0D4D) > > (U0D19) > >: "✄" # (U2704) white scissors, h/t David Wright > > : "ARGA WARGA IN THE DARGA instead of Z" > > Do you know what I see in four lines above, representing the content > of your ~/.XCompose file? I see "non-breaking space" characters > (two-byte sequences 0xc2a0). I see 8 of them in the last line alone > (the rule). Do you know what non-breaking space characters are? > > I'm not quite sure how best to describe them, myself. In TeX, you would type in Mr~Wright, because it's considered that Mr Wright is not the polite way to print a name in a book. I've never tested whether modern versions of text will handle Mr Wright directly as input, because using ~ explicitly has the advantage of making the modification more apparent. Otherwise, they're indistinguishable from spaces in text and on the command line, only showing in emacs, where they're coloured like all "idiosyncratic" whitespace. > But I will tell you what they *aren't*. They aren't spaces. They > aren't tabs. And the only thing their presence is going to do --in > your code and in your configuration files-- is wreak havoc. Similarly, a search like /Mr Wright will no longer work in less; you might have to search /Mr.Wright instead, with a wildcard. > Their name is very ironic. For our purposes, > > 1. they aren't spaces, and > 2. they break EVERYTHING. > > Whatever it is you are doing that puts them there, STOP DOING IT. > > […] > > > So, as Zeenan says, there is something fundamentally wrong in my > > system. I have to find that and correct it or reinstall everything. I would attempt to back out of the changes made. Removing/hiding .XCompose is an obvious first step. The keymap changes might be trickier: are there changes in /usr/share/X11/kbd/ or have they only added files in /etc/X11/kbd/? I know knothing about DE menus. It would appear from others' posts that DEs can change anything and everything. > > > firefox-esr issued the following errors, which appear to be explanatory: > > > (firefox-esr:11619): Gtk-WARNING **: 16:27:05.630: GTK+ supports to > > > output one char only: I've never tried to do anything about special characters with FF. They either work (like ½) in both the address and search bars, or I expect google or whatever to sort it out like typos (cf role and rôle).
Re: /sbin -> usr/sbin
Charles Plessy a écrit : > Le Sat, Jul 11, 2020 at 10:10:52AM +0200, BERTRAND Joël a écrit : >> >> Au lieu de faire cela, les devs de Debian seraient inspirés d'avoir un >> répertoire /rescue avec le contenu de /bin, /sbin et le gestionnaire >> de paquets compilé en statique. > > Bonjour Joël, > > une image Grml prête sur une partition de secours ne serait-elle pas > suffisante ? > Bonjour Charles, Pourquoi faire simple quand on peut faire compliqué ;-) Le /rescue de NetBSD par exemple évolue avec le système. Il n'y a pas de mise à jour nécessaire (plus que celle du système) et les outils qui s'y trouvent sont toujours ceux capables de dépanner le système (dans les bonnes versions). Il m'est déjà arrivé des soucis avec une debian et avec un gestionnaire de paquet dans une version de l'image GRML qui n'était pas capable de remettre d'équerre le système à dépanner qui était dans une autre version. C'est bien pour cela que je trouve très bête (et je suis poli) le fait d'avoir ces liens de / vers /usr alors que le bon sens voudrait _au contraire_ que l'on sépare bien ce qui est de l'ordre du mécanisme de démarrage de ce qui est de l'ordre de l'utilisation du système une fois celui-ci démarré. Certaines décisions me semblent prises sous l'effet de la mode (pour ne pas dire sous l'effet de la drogue...) par des gens qui n'ont pas réfléchi plus que cela à ce qui se faisait par ailleurs. Si /bin, /sbin, /usr/bin et /usr/sbin ont été séparés depuis trente ans, il y a peut-être des raisons fondamentales, ceux qui ont fait ces choix n'étant pas plus bêtes que nous. Dans un NetBSD, il n'y a typiquement pas besoin d'avoir une image rescue quelque part parce qu'il existe ce répertoire /rescue et que /bin, /lib et /sbin (et /etc) ne servent qu'au démarrage. Exemple : legendre:[~] > uname -a NetBSD legendre.systella.fr 9.0_STABLE NetBSD 9.0_STABLE (CUSTOM) #6: Sat Jun 6 16:01:51 CEST 2020 r...@legendre.systella.fr:/usr/src/netbsd-9/obj/sys/arch/amd64/compile/CUSTOM amd64 legendre:[~] > du -hs /bin 1.7M. legendre:[~] > du -hs /sbin 12M /sbin legendre:[~] > du -hs /lib 18M /lib legendre:[~] > du -hs /rescue 20M /rescue legendre:[~] > du -hs /stand/amd64/9.0 23M /stand/amd64/9.0 Pour peu que tu aies cela sur une partition séparée (en lecture seule), tu peux toujours redémarrer même ne cas d'effacement d'une bibliothèque critique (/rescue est là pour cela). /rescue te permet de travailler sur le vrai système sans jouer du mount -o bind et autres joyeusetés qui sont assez rapidement plantogènes pour peu que le noyau de l'image ne soit pas celui en cours sur le système à dépanner. En mettant un lien de /sbin vers /usr/sbin, tu t'interdis cela (disons que tu augmentes les chances que ça se passe mal). Exemple sur un serveur Debian : rayleigh:[~] > uname -a Linux rayleigh 5.6.0-2-amd64 #1 SMP Debian 5.6.14-1 (2020-05-23) x86_64 GNU/Linux rayleigh:[~] > du -hs /bin 12M /bin rayleigh:[~] > du -hs /usr/bin 1,1G/usr/bin rayleigh:[~] > du -hs /usr/sbin 64M /usr/sbin rayleigh:[~] > du -hs /sbin 17M /sbin Pour démarrer, j'ai _déjà_ besoin d'accéder à une partition en forme (assez en forme pour être montée en ro) de 1,2 Go, voire deux partitions en forme dans le cas où /usr est distinct et où on joue avec initramfs. Et si une bibliothèque cruciale est corrompue, je n'ai que mes yeux pour pleurer, je n'ai aucun utilitaire compilé en statique pour réparer. Quiconque a déjà essayé de recompiler un apt en statique verra de quoi je veux parler. Remarque bien, pour démarrer correctement un linux de nos jours, il faut aussi que l'initramfs soit correct. Encore un truc qui est une aberration sans nom puisque les scripts appelés ne sont pas forcément ceux de /etc, mais ceux qui ont été copiés dans l'initramfs. Je conçois qu'on embarque des modules dans un système de fichiers spécial pour contourner les problèmes d'initialisation liés au bios. Mais on peut faire largement mieux avec un système comme grub2 sans passer par cette horreur qu'est l'initramfs et qui est une source d'ennuis. Bien cordialement, JKB
Re: /sbin -> usr/sbin
Le 11/07/2020 à 15:06, Charles Plessy a écrit : Le Sat, Jul 11, 2020 at 10:10:52AM +0200, BERTRAND Joël a écrit : Au lieu de faire cela, les devs de Debian seraient inspirés d'avoir un répertoire /rescue avec le contenu de /bin, /sbin et le gestionnaire de paquets compilé en statique. Bonjour Joël, une image Grml prête sur une partition de secours ne serait-elle pas suffisante ? Bon week-end, Charles Pas besoin de partition de secours. Il suffit de mettre l'image Grml à /boot/grml et de faire "update-grub". ciao Klaus
Re: /sbin -> usr/sbin
Le Sat, Jul 11, 2020 at 10:10:52AM +0200, BERTRAND Joël a écrit : > > Au lieu de faire cela, les devs de Debian seraient inspirés d'avoir un > répertoire /rescue avec le contenu de /bin, /sbin et le gestionnaire > de paquets compilé en statique. Bonjour Joël, une image Grml prête sur une partition de secours ne serait-elle pas suffisante ? Bon week-end, Charles -- Charles Plessy Akano, Uruma, Okinawa, Japan
Re: Using .XCompose
On Sat, 11 Jul 2020 davidson wrote: On Fri, 10 Jul 2020 Ajith R wrote: Hi, Thanks for your experiment. The fact that it works atleast in some applications gives hope. There remains the strange fact that in no application (yet) have we seen *both* properties: 1. application produces multiple characters in accordance with XCompose rule that specifies this 2. application displays the sequence of the three unicode characters U+0D19 U+0D4D U+0D19 as the appropriate geminate glyph [snip] The "appropriate geminate glyph" refered to in property (2) above is illustrated in this table, [WHEN *cough* ...viewed with an application possessing property (2)] in the "ligated" row under the column headed "ṅṅa". https://en.wikipedia.org/wiki/Malayalam_script#Common_consonant_ligatures
Re: Browsers crashing in Bullseye armhf
* On 2020 10 Jul 23:40 -0500, Bruce Kerr wrote: > Hi, I have both Chromium and Epiphany browsers crashing randomly in > Bullseye running on Acer A500 tegra 2 tablet with kerenl 5.8.3. > > The version of Chromium on bullseye is 83. Not just armhf but amd64 as well. Since the upgrade it seems Chromium 83 will just crash and clear the screen on even the simplest Web page. I've observed this on both Buster and Bullseye. - Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: https://www.n0nb.us Projects: https://github.com/N0NB GPG fingerprint: 82D6 4F6B 0E67 CD41 F689 BBA6 FB2C 5130 D55A 8819 signature.asc Description: PGP signature
Re: Using .XCompose
On Fri, 10 Jul 2020 Ajith R wrote: Hi, Thanks for your experiment. The fact that it works atleast in some applications gives hope. There remains the strange fact that in no application (yet) have we seen *both* properties: 1. application produces multiple characters in accordance with XCompose rule that specifies this 2. application displays the sequence of the three unicode characters U+0D19 U+0D4D U+0D19 as the appropriate geminate glyph I found xterm and mlterm to have property (1), and some graphical browsers (firefox-esr and qutebrowser) to have property (2). We have not yet seen anything do both. (Actually, I have just learned how to make firefox-esr do both. See GTK_IM_MODULE below.) Curious parties (like myself) wishing to understand the orthographic peculiarities at issue here, might find the following section of the Wikipedia entry on Malayalam script provides brief, helpful background: https://en.wikipedia.org/wiki/Malayalam_script#Ligatures The "appropriate geminate glyph" refered to in property (2) above is illustrated in this table, in the "ligated" row under the column headed "ṅṅa". https://en.wikipedia.org/wiki/Malayalam_script#Common_consonant_ligatures I copied your exact sentences to my compose file. In Konsole the command cat ~/.XCompose gives the result: include "%L" : "ങ്ങ" # Ajith's auto-geminate rule, (U0D19) => (U0D19) (U0D4D) (U0D19) : "✄" # (U2704) white scissors, h/t David Wright : "ARGA WARGA IN THE DARGA instead of Z" Do you know what I see in four lines above, representing the content of your ~/.XCompose file? I see "non-breaking space" characters (two-byte sequences 0xc2a0). I see 8 of them in the last line alone (the rule). Do you know what non-breaking space characters are? I'm not quite sure how best to describe them, myself. But I will tell you what they *aren't*. They aren't spaces. They aren't tabs. And the only thing their presence is going to do --in your code and in your configuration files-- is wreak havoc. Their name is very ironic. For our purposes, 1. they aren't spaces, and 2. they break EVERYTHING. Whatever it is you are doing that puts them there, STOP DOING IT. You can print all lines of sometextfile which contain them by doing this: $ grep $'\xc2\xa0' sometextfile Next, I issued setxkbmap -layout us, just to make sure that the layout is us. I used konsole and UXterm to test Z. The test failed with Z remaining unchanged. The non-breaking spaces alone explain this much. So, as Zeenan says, there is something fundamentally wrong in my system. I have to find that and correct it or reinstall everything. Is the situation still as you describe here? 8 July 2020 Ajith R to debian-user https://lists.debian.org/msgid-search/620563117.3978825.1594226239...@mail.yahoo.com Now, things are even more strange. When I press the Caps Lock, a strange character appears. (I copy pasted it, searched the net and found it to be unicode compose character.) Then when I type s, the Caps Lock light gets switched on and the character S (caps) appears on screen. Then when I type X, the compose character and S become invisible and x/X doesn't appear. When I change focus to another window, the terminal in which I was typing shows the compose character and S. This behaviour has not changed after I unchecked the settings through KDE settings menu, after restarting computer, re-issuing xmodmap command or changing the layout to us. The same sequence is seen with typing in Kate as well. Even when I use Scroll Lock as the compose key, the situation is only different in that the s is not capitalised. If this is still so, we ought to figure out what's going on. To this end, I previously asked for the output of $ xmodmap and $ xmodmap -pk I tried in another computer with Debian and KDE. The Z gets replaced by the first letter in replacement string, while nothing happens in Xterm. Try again, for firefox-esr (and with a ~/.XCompose file that is not befouled with nonbreaking spaces). But make one change to the procedure. When you launch firefox-esr, do so like this: $ env GTK_IM_MODULE=xim firefox-esr Let us know how that goes. Is KDE the problem? I checked IceWM and got the same result. into what appears (to my utterly ignorant eye) to be a "freshly synthetic" glyph That "freshly synthetic" glyph would be the geminate form. I must say that the more I learn about the project you outlined in your original post, the more interesting it becomes. May I ask how you happened to find the post about providing linux support for the Breton keyboard https://dominiko.livejournal.com/20206.html which you mentioned in this 7 July reply to David Wright? https://lists.debian.org/msgid-search/563409927.3312315.1594115078...@mail.yahoo.com However it is that you came across it, that is a very interesting case as well. firefox-esr issued the following errors, which
Re: /sbin -> usr/sbin
Charles Plessy a écrit : > Le Sat, Jul 11, 2020 at 12:10:07AM +0200, BERTRAND Joël a écrit : >> >> Je viens d'installer une debian/testing toute fraîche sur un portable >> Toshiba et j'ai été surpris de trouver dans / des liens vers /usr : > > Bonjour Bertrand, > > c'est dans les notes de publication: > > https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.fr.html#merged-usr > > Bonne fin de semaine, > > Charles Merci à tous, ça m'avait échappé. Je viens de parcourir les liens fournis et c'est vraiment une bêtise monumentale d'autant que je n'ai vu aucune option, nulle part, pour éviter ce comportement à la noix. La justification de la chose est vraiment spécieuse et c'est vraiment ce genre de truc qui fait que j'abandonne de plus en plus les linuxeries. Et le fait que Debian est la dernière à franchir le pas n'est vraiment pas un argument valable. Je cite : "Amélioration de la compatibilité avec les autres Unix / Linux dans le comportement. Après la fusion avec /usr, tous les binaires deviennent disponibles respectivement dans : _ _ “/bin <–> /usr/bin” _"/sbin <–> /usr/sbin _ "/lib <–> /usr/lib" _simplement parce que /bin devient un lien symbolique vers /usr/bin, resp /sbin vers /usr/sbin… _ Cela signifie que les scripts/programmes écrits pour d’autres Unix ou d’autres Linux et portés à la distribution courante n’auront plus besoin de correction pour les chemins de système de fichiers des binaires appelés, ce qui est par ailleurs une source majeure de frustration. /usr/bin et /bin (resp. /Usr/sbin et /sbin, …) deviennent tout à fait équivalents." J'ai rarement lu un truc aussi bête. /bin et /sbin contiennent les binaires nécessaires du démarrage du système, /usr/bin et /usr/sbin les autres. C'est simple, carré. Par ailleurs, les scripts doivent utiliser une variable PATH, donc ce problème n'existe pas. "Amélioration de la compatibilité avec les systèmes de compilation GNU: la majeure partie du logiciel Linux est construite avec GNU autoconf / automake (c’est-à-dire GNU autotools), qui ignorent la division /usr spécifique à Linux. Le maintien de la division /usr nécessite une gestion non triviale du projet dans le système de génération en amont et dans les packages de votre distribution. Avec la fusion /usr, ce travail devient inutile et le portage des paquets vers Linux devient plus simple." Euh... J'utilise les autotools depuis 25 ans, je n'ai jamais constaté cela (sauf si les scripts sont écrits par des pieds, mais dans ce cas, pourquoi mettre un cataplasme sur une jambe de bois ? On corrige en amont, on ne fait pas n'importe quoi en aval !). Les autotools sont _justement_ faits pour gérer ce genre de problème. Quant à parler de la compatibilité Solaris, il y a un truc que les gens oublient, c'est que Solaris est livré comme un tout et que, à l'instar des BSD, /usr concerne le seul système. La dernière fois que j'ai eu un Solaris entre les pattes (un 10, j'avoue), les programmes autres que ceux du système étaient dans /opt ou /usr/local. Chez Debian, ce n'est pas le cas, ils sont dans /usr/bin. Un système Unix, quel qu'il soit, doit démarrer avec un système racine qui contient : - /etc - /bin - /sbin - /lib et c'est tout. Je sais bien qu'on peut bricoler avec initramfs, mais ça reste du bricolage pour contourner un problème qui ne devrait pas exister. initramfs est déjà un truc qui ne devrait pas exister dans un système de démarrage bien conçu (et qui est source d'un certain nombre de problèmes amusants). /usr qui contient les programmes utilisateurs doit être monté plus tard, comme /usr/local s'il est sur une partition à part, /opt, /var et /home. Comme chez Debian, on se prend les programmes installés dans /usr (donc dans /usr/bin et /usr/sbin), on se trimballe une partition /usr qui peut assez rapidement être énorme. Cette décision pourrait à la limite être compréhensible si les paquets non nécessaires au système étaient dans /usr/local ou /opt, mais pas en vrac dans /usr. Sur mes serveurs critiques (enfin, ceux qu'il me reste à fonctionner sous Linux), j'ai un / qui occupe 2Go (sur du raid1), alors que /usr en fait une quarantaine. Certaines partitions sont même en read-only pour éviter les problèmes. Vous allez me dire que c'est encore possible en jouant de l'initramfs. Certes, mais si /usr est montée en rw et dégage sur une corruption du fs, c'est tout le système qui est mort, alors que si / est en ro, on redémarre. Il faut vraiment que je trouve le temps de rajouter dans NetBSD les quelques trucs qui me manquent pour remplacer mes derniers serveurs Linux par des BSD. Entre dbus qui fait des siennes, systemd qui est d'une fiabilité douteuse dès qu'on n'est plus sur un desktop, usrmerge et d'autres "fonctionnalités" douteuses comme le renommage des interfaces réseau qui un coup fonctionne, un coup ne fonctionne plus (dépendant de la version de systemd sinon ce n'est pas drôle),
Re: Browsers crashing in Bullseye armhf
On Sat, Jul 11, 2020 at 02:23:31PM +1000, Bruce Kerr wrote: > Hi, I have both Chromium and Epiphany browsers crashing randomly in > Bullseye running on Acer A500 tegra 2 tablet with kerenl 5.8.3. > > The version of Chromium on bullseye is 83. > > I also have Buster with Chromium 79 and same kernel and all works fine, > including epiphany. > > I suspect it is a common lib used by both [...] Another thing to watch out would be the OOM killer: the other common characteristic of browsers is that they all want your RAM. Cheers -- t signature.asc Description: Digital signature
