On Wed, 5 Jul 2017 at 02:48:31 -0700
Rick Moen wrote:
> Quoting Alessandro Selli (alessandrose...@linux.com):
>
>>> 'It cannot work if what you need to do is feeding the HD controller some
>>> proprietary firmware that cannot legally be embedded in the GPL driver.'
>>>
>>> Has nothing whatsover t
Quoting Alessandro Selli (alessandrose...@linux.com):
> > 'It cannot work if what you need to do is feeding the HD controller some
> > proprietary firmware that cannot legally be embedded in the GPL driver.'
> >
> > Has nothing whatsover to do with distribution. Obviously.
>
> It obviously doe
On Wed, 5 Jul 2017 at 01:49:30 -0700
Rick Moen wrote:
> Quoting Alessandro Selli (alessandrose...@linux.com):
>
>> I twice quoted the thread proving what I reported was just what was been
>> discussed.
>
> 'It cannot work if what you need to do is feeding the HD controller some
> proprietary
Quoting Antony Stone (antony.st...@devuan.open.source.it):
> Not at all - I have that as a standard sig on all my list postings. If you
> had something similar I would have replied to you differently.
It's OK with me either way. I was just amused by the contrast between
you going _out of your
On Wednesday 05 July 2017 at 10:57:07, Rick Moen wrote:
> Quoting Antony Stone:
> > Would you two please take your personal flame war offlist, and argue with
> > each other in private?
>
> I've twice asked the other gentleman to please go away and argue with
> someone else. I hope that helps.
I
Oh, by the way, Anthony, I notice you had:
> From: Antony Stone
> To: dng@lists.dyne.org, Rick Moen ,
> Alessandro Selli
but also:
>Please reply to the list;
> please *don't* CC
Quoting Antony Stone (antony.st...@devuan.open.source.it):
> Would you two please take your personal flame war offlist, and argue with
> each
> other in private?
I've twice asked the other gentleman to please go away and argue with
someone else. I hope that helps.
As to the rest, the record s
On Wednesday 05 July 2017 at 10:49:30, Rick Moen wrote:
> Quoting Alessandro Selli (alessandrose...@linux.com):
> > I twice quoted the thread proving what I reported was just what was
> > been
> >
> > discussed.
>
> 'It cannot work if what you need to do is feeding the HD controller some
> p
Quoting Alessandro Selli (alessandrose...@linux.com):
> I twice quoted the thread proving what I reported was just what was been
> discussed.
'It cannot work if what you need to do is feeding the HD controller some
proprietary firmware that cannot legally be embedded in the GPL driver.'
Has n
On Wed, 5 Jul 2017 at 01:16:46 -0700
Rick Moen wrote:
> Quoting Alessandro Selli (alessandrose...@linux.com):
>
>> It was and it stayed centered there, no matter how much you insist in
>> stating the opposite. I already provided proof of it.
>
> Your actual wording, which I quoted, says otherwis
Quoting Alessandro Selli (alessandrose...@linux.com):
> It was and it stayed centered there, no matter how much you insist in
> stating the opposite. I already provided proof of it.
Your actual wording, which I quoted, says otherwise. Have a great day.
_
On Tue, 4 Jul 2017 at 23:55:30 -0700
Rick Moen wrote:
> Quoting Alessandro Selli (alessandrose...@linux.com):
>
> > It is relevant in proving you cannot do that and *lawfully* distribute
> > the module, which is what I have kept saying.
>
> Indeed, you do keep trying to change the topic to dis
Quoting Alessandro Selli (alessandrose...@linux.com):
> It is relevant in proving you cannot do that and *lawfully* distribute the
> module, which is what I have kept saying.
Indeed, you do keep trying to change the topic to distribution. But I
already pointed that out. ;->
> I am not turni
On 05/07/2017 at 01:52, Rick Moen wrote:
> Quoting Alessandro Selli (alessandrose...@linux.com):
>
> [b43 firmware BLOB]
>
>> It goes there *after* is was extracted out of the proprietary driver.
>
> I'm of course aware of that -- but that's irrelevant to what I was
> saying, which is that it
Le 04/07/2017 à 13:08, Alessandro Selli a écrit :
Right, which brings up the issue that you cannot produce a distibution
without an initramfs because, among the other problems, some of the drivers
it comes with, some of which are needed to mount the root filesystem, do need
a proprietary firmw
Quoting Alessandro Selli (alessandrose...@linux.com):
[b43 firmware BLOB]
> It goes there *after* is was extracted out of the proprietary driver.
I'm of course aware of that -- but that's irrelevant to what I was
saying, which is that it fails to qualify as an example of compiling a
firmware B
> Which, as noted, is you changing the subject: At the point where I
> pointed out your mistake, you were talking about compiling firmware into
> GPL drivers, not distribution.
Here is, again, the full evolution of the current discussion:
Author: Gary Olzeke
Date: 2017-06-22 23:02 +2
Quoting Alessandro Selli (alessandrose...@linux.com):
> You are still failing the easiest way to demonstrate your point:
Non-sequitur argument noted in passing.
> It's not just *my* experience, it's a long established fact. I also
> provided with pointers to a relevant example...
Sorry, th
On Tue, 4 Jul 2017 at 14:41:28 -0700
Rick Moen wrote:
> Quoting Alessandro Selli (alessandrose...@linux.com):
>
>> On Mon, 3 Jul 2017 at 13:06:41 -0700
>> Rick Moen wrote:
>>
>> > Your upthread hypothetical didn't mention Devuan at all.
>>
>> Of course it did.
>
> What you said, verbatim
Quoting Alessandro Selli (alessandrose...@linux.com):
> On Mon, 3 Jul 2017 at 13:06:41 -0700
> Rick Moen wrote:
>
> > Your upthread hypothetical didn't mention Devuan at all.
>
> Of course it did.
What you said, verbatim and without any qualifications, was 'It cannot
work if what you need to d
On Tue, 4 Jul 2017 at 14:12:09 +0200
Alessandro Selli wrote:
[...]
> They are advanced, mostly SAS and FC controllers, maybe some iSCSI
> device too. Mostly Enterprise hardware, not consumer-PC.
I did a quick search, all (or at least most) devices on the first page were
hardware RAID control
On Tue, 4 Jul 2017 at 12:44:34 +0100
KatolaZ wrote:
> On Tue, Jul 04, 2017 at 01:08:24PM +0200, Alessandro Selli wrote:
>
> [cut]
>
>>
>> Right, which brings up the issue that you cannot produce a distibution
>> without an initramfs because, among the other problems, some of the
>> drivers it
On Di, Jul 04, 2017 at 12:44:34 +0100, KatolaZ wrote:
Uh? Which are those proprietary drivers needed to mount the root
filesystem? AFAICT, Linux-libre is able to mount almost any
filesystem, from almost any existing storage device, without requiring
any proprietary binary blob at all.
There ar
On Tue, Jul 04, 2017 at 01:08:24PM +0200, Alessandro Selli wrote:
[cut]
>
> Right, which brings up the issue that you cannot produce a distibution
> without an initramfs because, among the other problems, some of the drivers
> it comes with, some of which are needed to mount the root filesyste
On Tue, 4 Jul 2017 at 11:41:05 +0100
KatolaZ wrote:
> On Tue, Jul 04, 2017 at 12:18:19PM +0200, Alessandro Selli wrote:
>
> [cut]
>
> > > didn't involve a right
> > > reserved under copyright in the first place,
> >
> > Let me remind you GPL is a licence, and that it prohibits linking
> > pr
On Tue, Jul 04, 2017 at 12:18:19PM +0200, Alessandro Selli wrote:
[cut]
> > didn't involve a right
> > reserved under copyright in the first place,
>
> Let me remind you GPL is a licence, and that it prohibits linking
> proprietary code with free code in the same binary file.
>
Sorry, but th
roprietary code with free code in the same binary file.
> suggesting you were perhaps
> thinking of redistribution, which you hadn't been talking about.
The object was:
Author: Gary Olzeke
Date: 2017-06-22 23:02 +200
To: dng
Subject: [DNG] some ASCII issues
Writes about issues
Quoting Alessandro Selli (alessandrose...@linux.com):
> On Sun, 2 Jul 2017 at 17:51:48 -0700
> Rick Moen wrote:
>
> > Quoting Alessandro Selli (alessandrose...@linux.com):
> >
> >> It cannot work if what you need to do is feeding the HD controller some
> >> proprietary firmware that cannot legal
On Mon, 3 Jul 2017 02:00:22 +0200, Alessandro wrote in message
<20170703020022.7ede7fb3@ayu>:
> On Mon, 3 Jul at 2017 01:03:13 +0200
> Arnt Karlsen wrote:
>
> > On Mon, 3 Jul 2017 00:42:52 +0200, Alessandro wrote in message
> > <20170703004252.748a9c7f@ayu>:
> >
> >> Il giorno Wed, 28 Jun 201
On Sun, 2 Jul 2017 at 17:51:48 -0700
Rick Moen wrote:
> Quoting Alessandro Selli (alessandrose...@linux.com):
>
>> It cannot work if what you need to do is feeding the HD controller some
>> proprietary firmware that cannot legally be embedded in the GPL driver.
>
> ITYM that the resulting derivat
Quoting Alessandro Selli (alessandrose...@linux.com):
> It cannot work if what you need to do is feeding the HD controller some
> proprietary firmware that cannot legally be embedded in the GPL driver.
ITYM that the resulting derivative work cannot be lawfully
redistributed. But compiling the dr
On Mon, 3 Jul 2017 at 01:03:13 +0200
Arnt Karlsen wrote:
> On Mon, 3 Jul 2017 00:42:52 +0200, Alessandro wrote in message
> <20170703004252.748a9c7f@ayu>:
>
>> Il giorno Wed, 28 Jun 2017 19:38:11 +0200
>> Didier Kryn ha scritto:
>>
>>> Le 28/06/2017 à 15:40, Stephan Seitz a écrit :
A
On Mon, 3 Jul at 2017 01:03:13 +0200
Arnt Karlsen wrote:
> On Mon, 3 Jul 2017 00:42:52 +0200, Alessandro wrote in message
> <20170703004252.748a9c7f@ayu>:
>
>> Il giorno Wed, 28 Jun 2017 19:38:11 +0200
>> Didier Kryn ha scritto:
>>
>>> Le 28/06/2017 à 15:40, Stephan Seitz a écrit :
>>> > And
On Mon, 3 Jul 2017 00:42:52 +0200, Alessandro wrote in message
<20170703004252.748a9c7f@ayu>:
> Il giorno Wed, 28 Jun 2017 19:38:11 +0200
> Didier Kryn ha scritto:
>
> > Le 28/06/2017 à 15:40, Stephan Seitz a écrit :
> > > And today you should always encrypt your discs.
> >
> > I don't
Il giorno Wed, 28 Jun 2017 19:38:11 +0200
Didier Kryn ha scritto:
> Le 28/06/2017 à 15:40, Stephan Seitz a écrit :
> > And today you should always encrypt your discs.
>
> I don't see any reason to encrypt /usr. You might like to encrypt
> /etc because it contains user names and (already
On Wed, 28 Jun 2017 at 08:09:21 -0700
Rick Moen wrote:
> Quoting Stephan Seitz (stse+dev...@fsing.rootsland.net):
>
> > That the kernel can’t find the root filesystem if it is encrypted?
> > And the kernel lacks the capability to ask you for the password.
>
> If you're correct that a kernal ca
On Tue, 27 Jun 2017 at 22:57:16 -0700
Rick Moen wrote:
> Quoting John Morris (jmor...@beau.org):
>
>> Nope, that negates one of the principle reasons to use an initramfs in
>> the first place. You assume the stock kernel can see the drive where
>> you intend to put this new partition; one of the
Adam Sampson:
...
> years. Since 2.6.37 (2011), the kernel lets you specify a partition in a
> GPT partition table by UUID:
>
> root=PARTUUID=39a734b6-4068-4ee7-8f6f-b6248588af37
...
Thanks, Adam for letting me know. And I found out that it is also
supported by mount with its -L and -U options.
Le 29/06/2017 à 01:08, Harald Arnesen a écrit :
Didier Kryn [2017-06-28 19:38]:
I don't see any reason to encrypt /usr. You might like to encrypt
/etc because it contains user names and (already encrypted) passwords.
But definitely there is no reason to encrypt everything.
But if you enc
Rick Moen [2017-06-28 20:33]:
> Temporary files in /tmp are sometimes a little sensitive and sometimes
> greatly so. (It's usually a tmpfs on my systems.) Operational paranoia
> suggests keeping it at least cleaned up frequently, if you're going to
> bother to have /home as a dmcrypt filesystem.
Didier Kryn [2017-06-28 19:38]:
> I don't see any reason to encrypt /usr. You might like to encrypt
> /etc because it contains user names and (already encrypted) passwords.
> But definitely there is no reason to encrypt everything.
But if you encrypt anything at all, isn't it easier to enc
Le 28/06/2017 à 20:33, Rick Moen a écrit :
Quoting Didier Kryn (k...@in2p3.fr):
I don't see any reason to encrypt /usr. You might like to
encrypt /etc because it contains user names and (already encrypted)
passwords. But definitely there is no reason to encrypt everything.
/home would be
Quoting Didier Kryn (k...@in2p3.fr):
> I don't see any reason to encrypt /usr. You might like to
> encrypt /etc because it contains user names and (already encrypted)
> passwords. But definitely there is no reason to encrypt everything.
/home would be where I keep anything that's sensitive.
Le 28/06/2017 à 15:40, Stephan Seitz a écrit :
And today you should always encrypt your discs.
I don't see any reason to encrypt /usr. You might like to encrypt
/etc because it contains user names and (already encrypted) passwords.
But definitely there is no reason to encrypt everything.
Quoting Stephan Seitz (stse+dev...@fsing.rootsland.net):
> That the kernel can’t find the root filesystem if it is encrypted?
> And the kernel lacks the capability to ask you for the password.
If you're correct that a kernal cannot find an encrypted rootfs, then by
the same token it cannot find a
On Mi, Jun 28, 2017 at 06:55:37 -0700, Rick Moen wrote:
Yes, and this will not work with new-school methods like disc
encryption because something needs to ask you for the password.
What exactly about LUKS is incompatible with use of a kernel compiled to
include all key drivers including those t
Quoting Stephan Seitz (stse+dev...@fsing.rootsland.net):
> On Di, Jun 27, 2017 at 10:57:16 -0700, Rick Moen wrote:
> >Step 1. Compile a kernel that includes inline all key drivers including
> >those needed to find the root filesystem.
> >Step 2. Profit!
> >That's the old-school method.
>
On Di, Jun 27, 2017 at 10:57:16 -0700, Rick Moen wrote:
Step 1. Compile a kernel that includes inline all key drivers including
those needed to find the root filesystem.
Step 2. Profit!
That's the old-school method.
Yes, and this will not work with new-school methods like disc encrypt
Quoting k...@aspodata.se (k...@aspodata.se):
> And that works when the root filesystem is on a device with fixed major/
> minor number, e.g. /dev/sda2 /dev/hda1, and even /dev/md1 for md
> devices with the old (0.90) format superblock if they are auto-assebled.
> It doesn't work for devices with
k...@aspodata.se writes:
> And that works when the root filesystem is on a device with fixed
> major/ minor number [...] It doesn't work for devices with dynamic
> device numbers.
That used to be true, but it's improved quite a bit in recent
years. Since 2.6.37 (2011), the kernel lets you specify
Rick Moen:
> Quoting John Morris (jmor...@beau.org):
>
> > Nope, that negates one of the principle reasons to use an initramfs in
> > the first place. You assume the stock kernel can see the drive where
> > you intend to put this new partition; one of the big drivers of initrd
> > in the first pl
Le 28/06/2017 à 07:47, John Morris a écrit :
On Sat, 2017-06-24 at 11:08 +0200, Didier Kryn wrote:
Anyway I think there's a simple method to live without the
initramfs. Everything which is done from initramfs could be done the
same way from a disk partition, which might make it easier to
Quoting John Morris (jmor...@beau.org):
> Nope, that negates one of the principle reasons to use an initramfs in
> the first place. You assume the stock kernel can see the drive where
> you intend to put this new partition; one of the big drivers of initrd
> in the first place was exotic hardware
On Sat, 2017-06-24 at 11:08 +0200, Didier Kryn wrote:
> Anyway I think there's a simple method to live without the
> initramfs. Everything which is done from initramfs could be done the
> same way from a disk partition, which might make it easier to debug:
> have a /os directory containing
On Sat, 2017-06-24 at 11:04 -0500, Don Wright wrote:
> Just teleport into the datacenter on the other side of the planet, or the
> office building where your after-hours key card doesn't work because all
> cards were cancelled following the alleged burglary last week*, or do some
> other Herculean
John Morris wrote:
>As for rescue, in the before time when the /usr split occurred, cheap
>live CD/USB stick rescue media was not an option. It is now.
Just teleport into the datacenter on the other side of the planet, or the
office building where your after-hours key card doesn't work because al
Le 24/06/2017 à 03:08, Steve Litt a écrit :
Think initramfs systems are cheap and easy? Making a working one
manually is tough: I've done it. And even using tools like dracut and
initramfs-tools is difficult and error prone.
Never used any tool for that. I crafted some initramfs and did it
On Fri, 23 Jun 2017 18:55:57 -0500
John Morris wrote:
> On Fri, 2017-06-23 at 16:41 +0200, Antony Stone wrote:
>
> > https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
> > if you want to start feeling annoyed as well as surprised.
>
> Dunno, that one actually makes a lot
Quoting John Morris (jmor...@beau.org):
> Dunno, that one actually makes a lot of sense.
At minimum, it's definitely not something to get religious over, so
nobody should be hyperventilating over it.
> The original reason no longer applies, we should all agree on that
> point, right?
Sure. Ro
On Fri, 2017-06-23 at 16:41 +0200, Antony Stone wrote:
> https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/ if
> you want to start feeling annoyed as well as surprised.
Dunno, that one actually makes a lot of sense. Applying the logic of
Chesterton's Fence here seems sound
Quoting k...@aspodata.se (k...@aspodata.se):
> I usually don't use initrd/initramfs so I don't like that merge.
> Also I want to have the ability to unmounting /usr if I would whish.
>
> If it is to make all binaries to be accessible as /usr/bin/whatever,
> one could make links from /usr/bin/ to
Didier:
> Le 23/06/2017 à 16:41, Antony Stone a écrit :
> > On Friday 23 June 2017 at 16:06:52, Jaromil wrote:
> >> On Thu, 22 Jun 2017, Hendrik Boom wrote:
> >>> Could that be a side effect of debian/systemd's fusion of /usr with /?
> >> ?!?!?! did they ?!?!?!
> >> how is this madness done, via mo
Le 23/06/2017 à 16:41, Antony Stone a écrit :
On Friday 23 June 2017 at 16:06:52, Jaromil wrote:
On Thu, 22 Jun 2017, Hendrik Boom wrote:
Could that be a side effect of debian/systemd's fusion of /usr with /?
?!?!?! did they ?!?!?!
how is this madness done, via mount -o bind
https://wi
On Friday 23 June 2017 at 16:06:52, Jaromil wrote:
> On Thu, 22 Jun 2017, Hendrik Boom wrote:
> >
> > Could that be a side effect of debian/systemd's fusion of /usr with /?
>
> ?!?!?! did they ?!?!?!
>
> how is this madness done, via mount -o bind
https://wiki.debian.org/UsrMerge
> Never
bash/nano all seems to be working fine now
didn't make any changes - afaik
these are my $PATHs:(all stock install)
olzeke51@devASCII:~/Desktop$ echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
root@devASCII:~# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin
On Thu, 22 Jun 2017, Hendrik Boom wrote:
> On Thu, Jun 22, 2017 at 05:02:54PM -0400, Gary Olzeke wrote:
> > bash couldn't find 'nano' (I wanted to copy the 'sandbox' message)
> > bash was looking in /usr/bin/nano - it was at /bin/nano [per 'which'
> > command]
>
> Could that be a side effect
On 06/22/2017 08:44 PM, Hendrik Boom wrote:
> On Thu, Jun 22, 2017 at 05:02:54PM -0400, Gary Olzeke wrote:
>> bash couldn't find 'nano' (I wanted to copy the 'sandbox' message)
>> bash was looking in /usr/bin/nano - it was at /bin/nano [per 'which'
>> command]
>
> Could that be a side effect o
On Thu, Jun 22, 2017 at 05:02:54PM -0400, Gary Olzeke wrote:
> bash couldn't find 'nano' (I wanted to copy the 'sandbox' message)
> bash was looking in /usr/bin/nano - it was at /bin/nano [per 'which'
> command]
Could that be a side effect of debian/systemd's fusion of /usr with /?
-- hendrik
dear Gary
On Thu, 22 Jun 2017, Gary Olzeke wrote:
>recently did an ASCII upgrade from the CD install Jessie 1.0-0 64 bit
>(see my ASCII-install_notes on [1]dev1galaxy.org forum)
hearing from multi/media issues just makes me think dyne:bolic will be
totally fine with good old jack1 and q
recently did an ASCII upgrade from the CD install Jessie 1.0-0 64 bit
(see my ASCII-install_notes on dev1galaxy.org forum)
'
these were some issues - I will start trying to debug them/investigate
and create bug reports
BUT I wanted to give a heads up!!
I didn't have these with the Jessie final vers
70 matches
Mail list logo
