Re: [DNG] (forw) Re: [skeptic] MINIX: ?Intel's hidden in-chip operating system
From: info at smallinnovations dot nl To: dng@lists.dyne.org Sent: Sunday, November 12, 2017 5:42 AM Subject: Re: [DNG] (forw) Re: [skeptic] MINIX: ?Intel's hidden in-chip operating system On 09-11-17 02:24, Rick Moen wrote: > Vaughan-Nichols's article is at > http://www.zdnet.com/article/minix-intels-hidden-in-chip-operating-system/ > > > - Forwarded message from Rick Moen - > > Date: Wed, 8 Nov 2017 17:19:35 -0800 > From: Rick Moen > To: skep...@linuxmafia.com > Subject: Re: [skeptic] MINIX: ?Intel's hidden in-chip operating system > Organization: If you lived here, you'd be $HOME already. > > Quoting Scott Peterson (scot...@mindspring.com), citing a mostly good > Steven J. Vaughan-Nichols's ZDnet article: > >> Buried deep inside your computer's Intel chip is the MINIX operating >> system and a software stack, which includes networking and a web >> server. It's slow, hard to get at, and insecure as insecure can be. [...] > > Garrett's AMT FAQ makes good reading for people wanting to know more. > https://mjg59.dreamwidth.org/48429.html?thread=1840429 > > This includes the fact that by _no_ means do all Intel chipsets > possessing ME firmware also have AMT code that runs on it -- and how to > query your machine to find out if it does. Most Intel systems don't > have AMT. Most Intel systems with AMT don't have it turned on. > > It also includes the fact that the biggest concern is remote access to > the AMT. If that isn't enabled, and there are various ways to ensure > that it isn't, that concern (a remote backdoor) goes away. > > > ___ > skeptic mailing list > skep...@linuxmafia.com > http://linuxmafia.com/mailman/listinfo/skeptic > To reach the listadmin, mail r...@linuxmafia.com > > - End forwarded message - > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng When reading https://www.theregister.co.uk/2017/11/09/chipzilla_come_closer_closer_listen_dump_ime/ where some claim to be able to access ME via USB ports I wonder how long it takes before ME is enabled and abused by malware. Grtz Nick ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng Does this imply that after the JTAG is fully exploited, the contents of ME could be extracted,dis-assembled, updated, and reloaded to allow the machine to boot and run? And could the ME be updatedfrom the selfsame machine by cross-connecting two USB ports? Just thinking out loud. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Documentation format philosophies
On Sun, 12 Nov 2017 00:39:34 +0100 Svante Signell wrote: > On Sat, 2017-11-11 at 13:33 -0500, Steve Litt wrote: > > > > > We use LaTEX in technical documents, > > > > LaTeX is wonderful *for what it does*, which is make beautifully > > typeset documents whose linefeeds are determined at compile time, > > not at read time (like ePub, HTML or Xhtml). The problem is that > > you can't reasonably convert LaTeX to XML, HTML, Xhtml or the > > like. > > Ever heard about latex2html? Tell me more about it. Have you used it to convert a significant LaTeX document to HTML? If so, was it real, semantic HTML, or did the system do early style to appearance conversions? Do you think the resulting HTML would be reasonable input to an ePub creation process? I tried to try it out, but it was very complicated to install (on Void Linux) and the documentation was at once voluminous and useless. Thanks, SteveT Steve Litt November 2017 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable
On Sun, 12 Nov 2017 at 19:45:02 +0100
Adam Borowski wrote:
> On Sun, Nov 12, 2017 at 12:14:33PM +0100, Joerg Reisenweber wrote:
>> The "too much work" argument is a very embarrassing one - it's the
>> genuine duty of distro maintainers to take care of exactly such stuff.
>> The argument that something was "too much work" (for the distro
>> maintainers, or even the developers) is moot unless you're doing all that
>> for yourself or for developers instead of your users.
>> Claiming that a decision whether to put a package into /bin or /usr/bin
>> (resp *sbin*) was "too much work" is also outright silly, there's zero
>> additional workload in placing the package into the right location,
>> except for the needed knowhow and decision itself. It's just for the
>> laziness of developers of boot/init process when they demand to
>> indiscriminately have access to *all* existing binaries in /usr
>
> The work involved is not just "zero", it's _massive_. Have you looked at
> how extensive dependency chains can be for complex setups? Try mounting a
> filesystem over wifi that requires a fancy authentication daemon. Every
> involved package, and every library recursively depended upon by one of
> those packages, would need to be moved to /{bin,sbin,lib}/.
Looks trivial to me: /bin, /sbin executables have their dependencies and
libraries in /lib on the same filesystem, just like /usr/bin, /usr/sbin
and /usr/lib. What's so complicated?
> Debian, with its north of 1000 developers, decided that, despite trying,
> it's a lost cause. Do you think Devuan with 5 can do better?
Last time I checked, Devuan does allow having /usr on a separate filesystem
from /.
Alessandro
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] (forw) Re: [skeptic] MINIX: ?Intel's hidden in-chip operating system
Am Montag, 13. November 2017 schrieb dan pridgeon: > > From: info at smallinnovations dot nl > To: dng@lists.dyne.org > Sent: Sunday, November 12, 2017 5:42 AM > Subject: Re: [DNG] (forw) Re: [skeptic] MINIX: ?Intel's hidden in-chip > operating system > > On 09-11-17 02:24, Rick Moen wrote: > > Vaughan-Nichols's article is at > > http://www.zdnet.com/article/minix-intels-hidden-in-chip-operating-system/ > > > > > > - Forwarded message from Rick Moen - > > > > Date: Wed, 8 Nov 2017 17:19:35 -0800 > > From: Rick Moen > > To: skep...@linuxmafia.com > > Subject: Re: [skeptic] MINIX: ?Intel's hidden in-chip operating system > > Organization: If you lived here, you'd be $HOME already. > > > > Quoting Scott Peterson (scot...@mindspring.com), citing a mostly good > > Steven J. Vaughan-Nichols's ZDnet article: > > > >> Buried deep inside your computer's Intel chip is the MINIX operating > >> system and a software stack, which includes networking and a web > >> server. It's slow, hard to get at, and insecure as insecure can be. > [...] > > > > Garrett's AMT FAQ makes good reading for people wanting to know more. > > https://mjg59.dreamwidth.org/48429.html?thread=1840429 > > > > This includes the fact that by _no_ means do all Intel chipsets > > possessing ME firmware also have AMT code that runs on it -- and how to > > query your machine to find out if it does. Most Intel systems don't > > have AMT. Most Intel systems with AMT don't have it turned on. > > > > It also includes the fact that the biggest concern is remote access to > > the AMT. If that isn't enabled, and there are various ways to ensure > > that it isn't, that concern (a remote backdoor) goes away. > > > > > > ___ > > skeptic mailing list > > skep...@linuxmafia.com > > http://linuxmafia.com/mailman/listinfo/skeptic > > To reach the listadmin, mail r...@linuxmafia.com > > > > - End forwarded message - > > ___ > > Dng mailing list > > Dng@lists.dyne.org > > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > > When reading > https://www.theregister.co.uk/2017/11/09/chipzilla_come_closer_closer_listen_dump_ime/ > > where some claim to be able to access ME via USB ports I wonder how long > it takes before ME is enabled and abused by malware. You should include "lawful inspection" under the label "malware". And then, well, guess what ... Nik > > Grtz > > Nick > > ___ > Dng mailing list > Dng@lists.dyne.org > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng > > > Does this imply that after the JTAG is fully exploited, the contents of ME > could be extracted,dis-assembled, updated, and reloaded to allow the machine > to boot and run? And could the ME be updatedfrom the selfsame machine by > cross-connecting two USB ports? Just thinking out loud. > > -- Please do not email me anything that you are not comfortable also sharing with the NSA, CIA ... ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] *ERROR* radeon kernel modesetting for R600 or later requires firmware-linux-nonfree.
On Sat 11 November 2017 09:28:23 Adam Borowski wrote: > > Does it really make the card more "free" if the binary blob is built-in > > instead of being loaded at runtime? > > Somehow, RMS believes so. No, actually RMS/FSF doesn't care about "more free" or "more secure" for that particular topic of peripherals firmware- it's simply about "what we don't see, we may consider as a hw blackbox. If however we *see* that firmware then our rules apply". RMS and FSF can't accept that GPL only applies to code run on the *linux* APplication Environment CPU (and coprocesors sharing unaudited access to that code and user data), it's a mere problem of defining the "borders of their farm" refer http://talk.maemo.org/showthread.php?p=1396903&highlight=stallman#post1396903 >>>If the modem firmware can't be changed, it is effectively in ROM, so >>>it might as well be a circuit. It doesn't need to be considered as >>>software. For instance, the FSF can disregard it when judging whether to >>>endorse a product /j ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Libre computers (as I see you don't like ME/PSP) they exist!
On Fri, 10 Nov 2017 22:03:32 -0500 "taii...@gmx.com" wrote: > In case you don't notice my reply (but please keep replies on the ML > so everyone sees :D) OK, here it is... > > On 11/09/2017 12:32 PM, Steve Litt wrote: [snip] > > After Rick's posted Minix on Intel article, I'm going to stick with > > AMD even if it's more expensive, slower and hotter (and I'm not > > saying any of those things are true). [snip] > Intel ME / AMD PSP > Post 2013 AMD stuff is just as bad as Intel's, if a KGPE-D16/KCMA-D8 > (libre firmware available, RYF) socket G34/C32 isn't good enough you > can get a (brand new, very fast and very cool) TALOS 2 (POWER 9) > which has both libre firmware and hardware and will be RYF certified. > I play the latest games in a VM (vfio gfx card via iommu-gfx) with my > D16, in comparison a 4386/6328 CPU is equal to a FX-8310) > > POWER is the only libre performance CPU arch available now > http://raptorcs.com (TALOS 2 is made by the same company that made > the quality D8/D16 libre coreboot ports that I use) > It is a good deal for the performance you get (that is a low price > for high end server hardware, you would pay more with x86) The computers on your link cost $4500.00 and up. Bare bones mobos with processor and a little RAM cost $2300.00. I'm just not that much of a true-believer. Houses in my neighborhood cost very roughly $350,000.00. I like my privacy, but that doesn't mean I'd spend $1,000,000.00 on an equivalent house with a built-in faraday cage, small windows with retractible steel shutters, a drone-jammer for my property, and a whole house wall-vibrator to prevent spooks from using the old "listen with a laser reflection" trick. I value my safety, but I don't have an underground bunker with 40 guns, 10,000 rounds of ammo, 200 magazines, 500 pounds of tuna and sardines, 10,000 daily vitamin pills, 5,000 gallons of distilled water, and 30 one ounce gold coins. Some people value their safety that much: I'm not one of them. We all have our priorities, and for each of us, money's one of them. I'm not willing to pay $4800.00 for a computer that eliminates every last attack vector. I'm not even willing to spend the time to eliminate every last attack vector from my software, so I'm for sure not going to spend $4800 for a computer. SteveT Steve Litt November 2017 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable
On Sun, Nov 12, 2017 at 09:36:17PM +0100, Joerg Reisenweber wrote:
> On Sun 12 November 2017 19:45:02 Adam Borowski wrote:
> > On Sun, Nov 12, 2017 at 12:14:33PM +0100, Joerg Reisenweber wrote:
> > > The "too much work" argument is a very embarrassing one - it's the genuine
> > > duty of distro maintainers to take care of exactly such stuff. The
> > > argument
> > > that something was "too much work" (for the distro maintainers, or even
> > > the
> > > developers) is moot unless you're doing all that for yourself or for
> > > developers instead of your users.
> > > Claiming that a decision whether to put a package into /bin or /usr/bin
> > > (resp *sbin*) was "too much work" is also outright silly, there's zero
> > > additional workload in placing the package into the right location,
> > > except for the needed knowhow and decision itself. It's just for the
> > > laziness of developers of boot/init process when they demand to
> > > indiscriminately have access to *all* existing binaries in /usr
> >
> > The work involved is not just "zero", it's _massive_. Have you looked at
> > how extensive dependency chains can be for complex setups? Try mounting a
> > filesystem over wifi that requires a fancy authentication daemon.
>
> Sorry, I think when you take up on the task to develop and maintain an init
> system,
And what exactly developing an init system (which is unrelated to making a
distribution) has to do with this?
> and you want to mount a filesystem via WiFi (what a weird idea)
What's wrong with this?
> *before* you mounted /usr/
Most large companies use a non-trivial method of authentication, sometimes
downright bizarre.
>, and then you claim that's *too much work* aka too
> complicated for *you* to accomplish this the right way and thus you need all
> /usr/ in root, then really so sorry to tell you I think you're simply not up
> to the task at hand
Have you _tried_ doing so? Or even listened to anyone who did?
Supporting every use case -- even just use cases widespread in the wild --
is a massive task. That your machine at home is content with a particular
setup doesn't make it worthwhile to provide a separate scheme just to cater
for that special snowflake. A generic, powerful and low-effort scheme
exists (initrd) thus doing it the hard way is a waste of time. What's most
important, not _your_ time.
> Anyway thanks for proving my point that it's just about laziness (or - now I
> have to add - maybe mere incompetence) of the systemd cabal and freedesktop
> folks and other proponents of /usr( in rootfs.
And what exactly systemd has to do with this? Newsflash: Debian does _not_
run systemd inside initrd.
> > Every
> > involved package, and every library recursively depended upon by one of
> > those packages, would need to be moved to /{bin,sbin,lib}/.
> >
> > Debian, with its north of 1000 developers, decided that, despite trying,
> > it's a lost cause. Do you think Devuan with 5 can do better?
>
> Yes, since those 5 understand that the other 995+ don't give a damn about
> where /usr/ lives since their apps get started *after* init and mount of
> filesystems
It's way more than 5 people whose packages get run before remote (and even
local) filesystems get mounted. And those people are tired with jumping
through hoops for no benefit.
> > And if all you want is merely separate /usr, the whole extra cost is
> > installing "tiny-initramfs" which includes a trivial initrd whose features
> > (and complexity) are limited to:
> > * CPU microcode
> > * /usr
> > * root=UUID
> > * root on nfs in some configurations
> > * _very_ minimal module loading, with no real automation. This is usually
> > inadequate for distribution kernels, you need to recompile your kernel
> > with required pieces statically.
> >
> > At least microcode is mandatory on any modern x86 CPUs,
> >
> ...since this is *obviously* completely unrelated to mounting /usr/
> Why don't systemd and "friends" mount /usr/ via such minimal ramdisk?
initrd acts _before_ the filesystem /bin/init is on is even mounted.
It is possible to run a separate copy of systemd inside initrd, Red Hat
does so.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ Laws we want back: Poland, Dz.U. 1921 nr.30 poz.177 (also Dz.U.
⣾⠁⢰⠒⠀⣿⡁ 1920 nr.11 poz.61): Art.2: An official, guilty of accepting a gift
⢿⡄⠘⠷⠚⠋⠀ or another material benefit, or a promise thereof, [in matters
⠈⠳⣄ relevant to duties], shall be punished by death by shooting.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Documentation format philosophies
On Sun, Nov 12, 2017 at 09:35:09PM -0500, Steve Litt wrote: > On Sun, 12 Nov 2017 00:39:34 +0100 > Svante Signell wrote: > > > On Sat, 2017-11-11 at 13:33 -0500, Steve Litt wrote: > > > > > > > We use LaTEX in technical documents, > > > > > > LaTeX is wonderful *for what it does*, which is make beautifully > > > typeset documents whose linefeeds are determined at compile time, > > > not at read time (like ePub, HTML or Xhtml). The problem is that > > > you can't reasonably convert LaTeX to XML, HTML, Xhtml or the > > > like. > > > > Ever heard about latex2html? > > Tell me more about it. Have you used it to convert a significant LaTeX > document to HTML? If so, was it real, semantic HTML, or did the system > do early style to appearance conversions? Do you think the resulting > HTML would be reasonable input to an ePub creation process? > The whole discussion seem to have a little point to me. HTML is not "semantic" at all. So the only way you can convert a LaTeX document into HTML is by trying to match in HTML the visual style that LaTeX would have used to render the document. And the result will be lousy, as many others have pointed out, since LaTeX is a professional typesetting system meant for high-quality paged media, while HTML is a badly-designed, unstructured markup language. I am convinced that there is no single *perfect* way to write documentation, and that, unfortunately, different source formats are needed for documents with different purposes. I would never write a manpage in LaTeX or XML (actually, I would never write anything in XML, but that's another story) as I would never write a scientific paper in anything else than LaTeX. But I have done both things, at times, and even worse things with docs that I won't mention here :) The result is that, IMHO, the utopia of "write once, deliver in whatever format will come in the next 20 years" is doomed to remain an utopia. And complicating things to impossible levels using XML is not gonna help at all. I thing stuff like markdown and orgmode are more than fine for most of the manpage-wiki-tutorial-and-the-likes documentation, but you can't get much of eyecandies with them. As with programming languages, the only reasonable way to cope with document formats is probably to learn as many formatting systems as possible, and to use "the right one" for each task. My2Cents KatolaZ -- [ ~.,_ Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab ] [ "+. katolaz [at] freaknet.org --- katolaz [at] yahoo.it ] [ @) http://kalos.mine.nu --- Devuan GNU + Linux User ] [ @@) http://maths.qmul.ac.uk/~vnicosia -- GPG: 0B5F062F ] [ (@@@) Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ ] signature.asc Description: Digital signature ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable
On Sun, 12 Nov 2017 19:45:02 +0100 Adam Borowski wrote: > On Sun, Nov 12, 2017 at 12:14:33PM +0100, Joerg Reisenweber wrote: > > The "too much work" argument is a very embarrassing one - it's the > > genuine duty of distro maintainers to take care of exactly such > > stuff. The argument that something was "too much work" (for the > > distro maintainers, or even the developers) is moot unless you're > > doing all that for yourself or for developers instead of your > > users. Claiming that a decision whether to put a package into /bin > > or /usr/bin (resp *sbin*) was "too much work" is also outright > > silly, there's zero additional workload in placing the package into > > the right location, except for the needed knowhow and decision > > itself. It's just for the laziness of developers of boot/init > > process when they demand to indiscriminately have access to *all* > > existing binaries in /usr > > The work involved is not just "zero", it's _massive_. Have you > looked at how extensive dependency chains There's a reason /sbin stood for STATIC bin. > can be for complex setups? > Try mounting a filesystem over wifi that requires a fancy > authentication daemon. OK fine, for sure for sure. For the 10% doing ultra-unusual stuff, boot to a combined /bin. For the other 90%, the / partition can have an /sbin directory with the necessary static programs to mount the root partition. Once the root partition is mounted, /etc/fstab can be found and run. And yeah, you'll need some sort of directly-on-/ drivers and firmware too,for the common stuff. I'll bet 3/4 of the people can boot no-initramfs to an /ext? root, and mount /usr to do the rest of the mounts. The rest, which might be able to be considered an edge case, can use initramfs and boot to a joined /bin. How hard would it be to put the drivers for ext? monolithically in the kernel, along with necessary drivers for lvm and luks? One more thing: What did people do before maybe 2010, when /sbin, /bin, /usr/sbin, and /user/bin were four separate directories? Was life that hard back then? Were develpers smarter? SteveT Steve Litt November 2017 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Libre computers (as I see you don't like ME/PSP) they exist!
On 11/12/2017 09:06 PM, Steve Litt wrote: On Fri, 10 Nov 2017 22:03:32 -0500 "taii...@gmx.com" wrote: In case you don't notice my reply (but please keep replies on the ML so everyone sees :D) OK, here it is... On 11/09/2017 12:32 PM, Steve Litt wrote: [snip] After Rick's posted Minix on Intel article, I'm going to stick with AMD even if it's more expensive, slower and hotter (and I'm not saying any of those things are true). [snip] Intel ME / AMD PSP Post 2013 AMD stuff is just as bad as Intel's, if a KGPE-D16/KCMA-D8 (libre firmware available, RYF) socket G34/C32 isn't good enough you can get a (brand new, very fast and very cool) TALOS 2 (POWER 9) which has both libre firmware and hardware and will be RYF certified. I play the latest games in a VM (vfio gfx card via iommu-gfx) with my D16, in comparison a 4386/6328 CPU is equal to a FX-8310) POWER is the only libre performance CPU arch available now http://raptorcs.com (TALOS 2 is made by the same company that made the quality D8/D16 libre coreboot ports that I use) It is a good deal for the performance you get (that is a low price for high end server hardware, you would pay more with x86) The computers on your link cost $4500.00 and up. Bare bones mobos with processor and a little RAM cost $2300.00. I'm just not that much of a true-believer. Houses in my neighborhood cost very roughly $350,000.00. I like my privacy, but that doesn't mean I'd spend $1,000,000.00 on an equivalent house with a built-in faraday cage, small windows with retractible steel shutters, a drone-jammer for my property, and a whole house wall-vibrator to prevent spooks from using the old "listen with a laser reflection" trick. Haha those laser mics get you every time. I value my safety, but I don't have an underground bunker with 40 guns, 10,000 rounds of ammo, 200 magazines, 500 pounds of tuna and sardines, 10,000 daily vitamin pills, 5,000 gallons of distilled water, and 30 one ounce gold coins. Some people value their safety that much: I'm not one of them. We all have our priorities, and for each of us, money's one of them. I'm not willing to pay $4800.00 for a computer that eliminates every last attack vector. I'm not even willing to spend the time to eliminate every last attack vector from my software, so I'm for sure not going to spend $4800 for a computer. Of course - which is why I mentioned the x86-64 D8 and D16 - which while slower than POWER 9 are still quite fast with a $40 16 core CPU. You could build a complete setup for around $500 - at least I did. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Documentation format philosophies
On Sun, Nov 12, 2017 at 09:35:09PM -0500, Steve Litt wrote: > On Sun, 12 Nov 2017 00:39:34 +0100 > Svante Signell wrote: > > > On Sat, 2017-11-11 at 13:33 -0500, Steve Litt wrote: > > > > > > > We use LaTEX in technical documents, > > > > > > LaTeX is wonderful *for what it does*, which is make beautifully > > > typeset documents whose linefeeds are determined at compile time, > > > not at read time (like ePub, HTML or Xhtml). The problem is that > > > you can't reasonably convert LaTeX to XML, HTML, Xhtml or the > > > like. > > > > Ever heard about latex2html? Tried them all, and only one that was successful in most respects was the lwarp package. Haines Brown ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable
On Mon, Nov 13, 2017 at 01:14:43AM +0100, Alessandro Selli wrote:
> On Sun, 12 Nov 2017 at 19:45:02 +0100
> Adam Borowski wrote:
>
> > On Sun, Nov 12, 2017 at 12:14:33PM +0100, Joerg Reisenweber wrote:
> >> The "too much work" argument is a very embarrassing one - it's the
> >> genuine duty of distro maintainers to take care of exactly such stuff.
> >> The argument that something was "too much work" (for the distro
> >> maintainers, or even the developers) is moot unless you're doing all that
> >> for yourself or for developers instead of your users.
> >> Claiming that a decision whether to put a package into /bin or /usr/bin
> >> (resp *sbin*) was "too much work" is also outright silly, there's zero
> >> additional workload in placing the package into the right location,
> >> except for the needed knowhow and decision itself. It's just for the
> >> laziness of developers of boot/init process when they demand to
> >> indiscriminately have access to *all* existing binaries in /usr
> >
> > The work involved is not just "zero", it's _massive_. Have you looked at
> > how extensive dependency chains can be for complex setups? Try mounting a
> > filesystem over wifi that requires a fancy authentication daemon. Every
> > involved package, and every library recursively depended upon by one of
> > those packages, would need to be moved to /{bin,sbin,lib}/.
>
> Looks trivial to me: /bin, /sbin executables have their dependencies and
> libraries in /lib on the same filesystem, just like /usr/bin, /usr/sbin
> and /usr/lib. What's so complicated?
But _which_ executables and libraries?
Are you prepared to move for example Java to /bin|/lib? It's an insane
language, yet somehow loved by enterprisey stuff, and is needed to
authenticate. And its dependency chains are extensive. This is not just
Java, there are far, far more such weird (to us) setups.
There's no sane way to move libraries at install time -- an universal
distribution would have to put into /lib anything that even a single user
needs.
And then, imagine you're the maintainer of some random library. You don't
care about Java, yet someone wrote java bindings to your library. Suddenly
you'd need to move everything to /lib. Would you get angry?
At some point, you say "enough".
> > Debian, with its north of 1000 developers, decided that, despite trying,
> > it's a lost cause. Do you think Devuan with 5 can do better?
>
> Last time I checked, Devuan does allow having /usr on a separate filesystem
> from /.
Yes, but only if you use an initrd. Some simple cases might work as such
support was dropped only late during the Stretch development cycle, but in
the future, you'd need to change several hundred packages.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀ Laws we want back: Poland, Dz.U. 1921 nr.30 poz.177 (also Dz.U.
⣾⠁⢰⠒⠀⣿⡁ 1920 nr.11 poz.61): Art.2: An official, guilty of accepting a gift
⢿⡄⠘⠷⠚⠋⠀ or another material benefit, or a promise thereof, [in matters
⠈⠳⣄ relevant to duties], shall be punished by death by shooting.
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable
On Sun, Nov 12, 2017 at 04:09:21PM -0600, Patrick Meade wrote: > On 11/12/2017 12:45 PM, Adam Borowski wrote: > > At least microcode is mandatory on any modern x86 CPUs, or you risk severe > > data loss issues that differ by CPU sub-model. You may think that just > > because without microcode your machine boots, all is ok. It's not. Even > > worse, the documentation for problems fixed by microcode updates is sparse > > at best and non-existant in most cases. > > Will you share a link to a source for this? For example: https://lists.debian.org/debian-security/2016/03/msg00084.html An unprivileged user in an unprivileged VM gets to execute arbitrary code in the _host_'s kernel. There's hundreds of such CPU errata per year. They usually affect just a few models, yet there's enough to give a fair share to every CPU you may have. And, as Intel and AMD really don't want this to be public, most errata are fixed silently without an announcement. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ Laws we want back: Poland, Dz.U. 1921 nr.30 poz.177 (also Dz.U. ⣾⠁⢰⠒⠀⣿⡁ 1920 nr.11 poz.61): Art.2: An official, guilty of accepting a gift ⢿⡄⠘⠷⠚⠋⠀ or another material benefit, or a promise thereof, [in matters ⠈⠳⣄ relevant to duties], shall be punished by death by shooting. ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable
On Mon 13 November 2017 00:18:15 Adam Borowski wrote:
> On Sun, Nov 12, 2017 at 09:36:17PM +0100, Joerg Reisenweber wrote:
> > On Sun 12 November 2017 19:45:02 Adam Borowski wrote:
> > > On Sun, Nov 12, 2017 at 12:14:33PM +0100, Joerg Reisenweber wrote:
> > > > The "too much work" argument is a very embarrassing one - it's the
> > > > genuine
> > > > duty of distro maintainers to take care of exactly such stuff. The
> > > > argument
> > > > that something was "too much work" (for the distro maintainers, or
> > > > even
> > > > the
> > > > developers) is moot unless you're doing all that for yourself or for
> > > > developers instead of your users.
> > > > Claiming that a decision whether to put a package into /bin or
> > > > /usr/bin
> > > > (resp *sbin*) was "too much work" is also outright silly, there's zero
> > > > additional workload in placing the package into the right location,
> > > > except for the needed knowhow and decision itself. It's just for the
> > > > laziness of developers of boot/init process when they demand to
> > > > indiscriminately have access to *all* existing binaries in /usr
> > >
> > > The work involved is not just "zero", it's _massive_. Have you looked
> > > at
> > > how extensive dependency chains can be for complex setups? Try mounting
> > > a
> > > filesystem over wifi that requires a fancy authentication daemon.
> >
> > Sorry, I think when you take up on the task to develop and maintain an
> > init
> > system,
>
> And what exactly developing an init system (which is unrelated to making a
> distribution) has to do with this?
>
> > and you want to mount a filesystem via WiFi (what a weird idea)
>
> What's wrong with this?
>
> > *before* you mounted /usr/
>
> Most large companies use a non-trivial method of authentication, sometimes
> downright bizarre.
>
> >, and then you claim that's *too much work* aka too
> >
> > complicated for *you* to accomplish this the right way and thus you need
> > all /usr/ in root, then really so sorry to tell you I think you're simply
> > not up to the task at hand
>
> Have you _tried_ doing so? Or even listened to anyone who did?
>
> Supporting every use case -- even just use cases widespread in the wild --
> is a massive task. That your machine at home is content with a particular
> setup doesn't make it worthwhile to provide a separate scheme just to cater
> for that special snowflake. A generic, powerful and low-effort scheme
> exists (initrd) thus doing it the hard way is a waste of time. What's most
> important, not _your_ time.
>
> > Anyway thanks for proving my point that it's just about laziness (or - now
> > I have to add - maybe mere incompetence) of the systemd cabal and
> > freedesktop folks and other proponents of /usr( in rootfs.
>
> And what exactly systemd has to do with this? Newsflash: Debian does _not_
> run systemd inside initrd.
>
> > > Every
> > > involved package, and every library recursively depended upon by one of
> > > those packages, would need to be moved to /{bin,sbin,lib}/.
> > >
> > > Debian, with its north of 1000 developers, decided that, despite trying,
> > > it's a lost cause. Do you think Devuan with 5 can do better?
> >
> > Yes, since those 5 understand that the other 995+ don't give a damn about
> > where /usr/ lives since their apps get started *after* init and mount of
> > filesystems
>
> It's way more than 5 people whose packages get run before remote (and even
> local) filesystems get mounted. And those people are tired with jumping
> through hoops for no benefit.
>
> > > And if all you want is merely separate /usr, the whole extra cost is
> > > installing "tiny-initramfs" which includes a trivial initrd whose
> > > features
> > > (and complexity) are limited to:
> > > * CPU microcode
> > > * /usr
> > > * root=UUID
> > > * root on nfs in some configurations
> > > * _very_ minimal module loading, with no real automation. This is
> > > usually
> > >
> > > inadequate for distribution kernels, you need to recompile your kernel
> > > with required pieces statically.
> > >
> > > At least microcode is mandatory on any modern x86 CPUs,
> >
> > ...since this is *obviously* completely unrelated to mounting /usr/
> > Why don't systemd and "friends" mount /usr/ via such minimal ramdisk?
>
> initrd acts _before_ the filesystem /bin/init is on is even mounted.
>
> It is possible to run a separate copy of systemd inside initrd, Red Hat
> does so.
>
>
> Meow!
I can't see a single word of yours in your whole reply that is faintly related
to the original topic which been "have /usr/ in a separate volume that gets
mounted early in boot/init process, as opposed to keeping /usr/ on rootfs
because some nitwits think they don't need to care about dependencies in their
*EARLY BOOT* processes they develop/maintain"
No need to try and explain to me what's an intrd and how it works, rather it
seems your expertise and understanding on the whole init process and volume
mounting and de
Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable
On Sun 12 November 2017 21:54:36 Steve Litt wrote: > One more thing: What did people do before maybe 2010, > when /sbin, /bin, /usr/sbin, and /user/bin were four separate > directories? Was life that hard back then? Were develpers smarter? I'd bet all and my butt on the latter ;-) It's just too obvious. Maybe intitially it was just systemd cabal who noticed that managing dependencies in init process isn't exactly a nobrainer and thus (and because of feature creep like needing d-bus and other high level crap in init) and not willing to cope with the fallout that correctly beem described as dependency hell in package/lib dependencies decided to rather cram /usr/ into / - after all it's just in line with the monolithic approach of systemd at large. Now probably more and more devels simply take it as granted that they don't need to learn about deoendencies anymore. What a depressing thought :-/ /j ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] mdevd-0.0.1.0 - a mdev-compatible uevent manager
hello Didier Kryn: thanks for bringing this to my [and everyones] attention. My use of mdev "just seems to work", perhaps because I just use my computers for boring "desktop duties". I remember Devuan being very agressive when I tried to uninstall udev* [dragging many other important packages with it]. I like the idea of only using the built-in Busybox commands to init Linux [exceptions sdhcp and iptables]. I will explore mdevd properly when it gets closer to 1.0.0.0! thanks, jacksprat ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable
On 13/11/17 13:09, Joerg Reisenweber wrote: On Sun 12 November 2017 21:54:36 Steve Litt wrote: One more thing: What did people do before maybe 2010, when /sbin, /bin, /usr/sbin, and /user/bin were four separate directories? Was life that hard back then? Were develpers smarter? I'd bet all and my butt on the latter ;-) It's just too obvious. Maybe intitially it was just systemd cabal who noticed that managing dependencies in init process isn't exactly a nobrainer and thus (and because of feature creep like needing d-bus and other high level crap in init) and not willing to cope with the fallout that correctly beem described as dependency hell in package/lib dependencies decided to rather cram /usr/ into / systemd didn't exist in 1991 when USL decided that for SVR4.2 /bin, /lib and /sbin should just be symlinks to /usr. john@sylvania ~ > ls -l / | grep -e '->' lrwxrwxrwx 1 root sys 8 Apr 15 2005 bin -> /usr/bin lrwxrwxrwx 1 root sys 8 Apr 15 2005 ccs -> /usr/ccs lrwxrwxrwx 1 root sys 9 Apr 15 2005 lbin -> /usr/lbin lrwxrwxrwx 1 root sys 8 Apr 15 2005 lib -> /usr/lib lrwxrwxrwx 1 root sys 10 Apr 15 2005 share -> /usr/share lrwxrwxrwx 1 root sys 8 Apr 15 2005 shlib -> /usr/lib lrwxrwxrwx 1 root root 11 Apr 3 2017 unix -> /stand/unix (I don't have any machines still running UnixWare 1.0, hence the rather recent create dates). ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] Fwd: [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager
Le 13/11/2017 à 13:56, jacksprat a écrit : hello Didier Kryn: thanks for bringing this to my [and everyones] attention. My use of mdev "just seems to work", perhaps because I just use my computers for boring "desktop duties". I remember Devuan being very agressive when I tried to uninstall udev* [dragging many other important packages with it]. I like the idea of only using the built-in Busybox commands to init Linux [exceptions sdhcp and iptables]. I will explore mdevd properly when it gets closer to 1.0.0.0! thanks, jacksprat Actually I sent the information to Jacksprat only, because it's rather technical and he seems the guy most concerned. Now I have to give it to the list (-: A few weeks ago Laurent Bercot announced mdevd, a replacement for Busybox's mdev which solves some unpleasant details of mdev. Busybox's mdev is spawned by the kernel for every uevent, which can cause a "fork bomb" at start up (a concern for very small and slow systems); it parses its config file everytime, of course, and it needs a trick with a lock file to serialize the processing of the uevents. Instead, mdevd (Laurent's server) parses its config file (strictly identical to mdev's) only once and reads uevents from its standard input. It can be piped from a netlink reader (also provided), which is the way to process uevents on the fly, or from another application (also provided) which generates uevents from sysfs to update /dev with the uevents generated by the kernel before mdevd was started. Since mdevd gets its uevents from the netlink, they are naturally serialized. The (little) drawback of mdevd is that it is constantly present in the system, together with its netlink reader. Busybox's mdev, instead is only present shortly when there is an uevent. Here is the announcement: Message transféré Sujet : [announce] mdevd-0.0.1.0 - a mdev-compatible uevent manager Date : Mon, 23 Oct 2017 08:02:33 + De :Laurent Bercot Répondre à :Laurent Bercot Pour : skaw...@list.skarnet.org , busy...@busybox.net Hello, About two years ago, there was some talk on the Busybox mailing-list about the need for a version of "mdev" that would not use a separate process for every uevent (as a hotplug manager does) but that would act as a daemon, able to handle a series of uevents - typically read from the netlink. One of the goals of such a program was to reduce boot time on slow / resource-constrained devices that don't like creating hundreds of processes at the same time - especially when they contend for a sequence number. I took a quick look at the time, but came to the conclusion that the way mdev was coded made it very difficult. Basically, mdev gets its uevent variables from the environment, then reads and processes its config file, performing actions as it goes. A quick hack to add "daemon mode" support to mdev would still make it process the config file for every event, similarly to what "mdev -s" does; this would remove the forks but still be pretty inefficient, not to mention particularly ugly. To implement "daemon mode mdev" in a clean way, a full rewrite was needed. So I shelved the idea at the time. Until now. mdevd is an uevent manager reading a sequence of uevents and handling them without forking, that understands the full /etc/mdev.conf format. "mdevd-coldplug | mdevd" is equivalent to "mdev -s". "mdevd-netlink | mdevd" is a daemon that listens to the netlink and processes uevents sequentially, without the need for mdev.seq hacks coming from the kernel spawning hotplug managers in parallel. You can find it here: https://skarnet.org/software/mdevd/ git://git.skarnet.org/mdevd https://github.com/skarnet/mdevd Since it's a full rewrite with a very different architecture from mdev and little code reusability with the rest of Busybox, it did not make sense to include it in Busybox, which is why it's provided as a separate package. Bug-reports welcome. mdevd is still considered beta for some functionality I could not extensively test, such as firmware loading. If your setup uses firmware loading or otherwise obscure mdev features, I'm especially interested in your reports and/or comments. (mdevd comes with a dry run mode, so you don't have to be a reckless cowboy to test it.) Enjoy, -- Laurent ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
[DNG] mdevd-0.0.1.0 - a mdev-compatible uevent manager
Didier Kryn: sorry, I am new to MLs, and thought everything arriving from lists.dyne.org was in the same space. jacksprat ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] Libre computers (as I see you don't like ME/PSP) they exist!
On Mon, 13 Nov 2017 05:25:31 -0500 "taii...@gmx.com" wrote: > Of course - which is why I mentioned the x86-64 D8 and D16 - which > while slower than POWER 9 are still quite fast with a $40 16 core > CPU. You could build a complete setup for around $500 - at least I > did. Noww you're speaking my language. Do you have a URL to read about KGPE-D16/KCMA-D8? Thanks, SteveT Steve Litt November 2017 featured book: Troubleshooting: Just the Facts http://www.troubleshooters.com/tjust ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable
On Mon, 13 Nov 2017 at 12:42:50 +0100
Adam Borowski wrote:
> On Mon, Nov 13, 2017 at 01:14:43AM +0100, Alessandro Selli wrote:
>> On Sun, 12 Nov 2017 at 19:45:02 +0100
>> Adam Borowski wrote:
>>
>>> On Sun, Nov 12, 2017 at 12:14:33PM +0100, Joerg Reisenweber wrote:
The "too much work" argument is a very embarrassing one - it's the
genuine duty of distro maintainers to take care of exactly such stuff.
The argument that something was "too much work" (for the distro
maintainers, or even the developers) is moot unless you're doing all
that for yourself or for developers instead of your users.
Claiming that a decision whether to put a package into /bin or /usr/bin
(resp *sbin*) was "too much work" is also outright silly, there's zero
additional workload in placing the package into the right location,
except for the needed knowhow and decision itself. It's just for the
laziness of developers of boot/init process when they demand to
indiscriminately have access to *all* existing binaries in /usr
>>>
>>> The work involved is not just "zero", it's _massive_. Have you looked
>>> at how extensive dependency chains can be for complex setups? Try
>>> mounting a filesystem over wifi that requires a fancy authentication
>>> daemon. Every involved package, and every library recursively depended
>>> upon by one of those packages, would need to be moved
>>> to /{bin,sbin,lib}/.
>>
>> Looks trivial to me: /bin, /sbin executables have their dependencies and
>> libraries in /lib on the same filesystem, just like /usr/bin, /usr/sbin
>> and /usr/lib. What's so complicated?
>
> But _which_ executables and libraries?
Any ELF one.
> Are you prepared to move for example Java to /bin|/lib? It's an insane
> language, yet somehow loved by enterprisey stuff, and is needed to
> authenticate. And its dependency chains are extensive. This is not just
> Java, there are far, far more such weird (to us) setups.
Are you jocking? We were talking of the boot process on a machine
with /usr sitting on it's own partition. Do you know of some Unix that needs
Java to boot or to mount it's filesystems?
> There's no sane way to move libraries at install time -- an universal
> distribution would have to put into /lib anything that even a single user
> needs.
>
> And then, imagine you're the maintainer of some random library. You don't
> care about Java, yet someone wrote java bindings to your library. Suddenly
> you'd need to move everything to /lib. Would you get angry?
>
> At some point, you say "enough".
Yes, I would say "enought", but I would say so to coders who take absurd
design decisions.
>>> Debian, with its north of 1000 developers, decided that, despite trying,
>>> it's a lost cause. Do you think Devuan with 5 can do better?
>>
>> Last time I checked, Devuan does allow having /usr on a separate
>> filesystem from /.
>
> Yes, but only if you use an initrd.
I'm fine with it, I would need it just the same to unlock the cryptsetup'ed
root filesystem.
> Some simple cases might work as such
> support was dropped only late during the Stretch development cycle, but in
> the future, you'd need to change several hundred packages.
Just the same as with systemd, isn't it?
Alessandro
___
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
Re: [DNG] WARNING: lvm2 > 2.02.173-1 breaks some systems and make them unbootable
On Mon 13 November 2017 15:46:30 John Hughes wrote: > systemd didn't exist in 1991 when USL decided that for SVR4.2 /bin, /lib > and /sbin should just be symlinks to /usr. And when did USL (whoever that is) decide that SVR4.2 doesn't care about being able to run on any ARM SoC? And how's that relevant for Linux? ___ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
