Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs

On Thursday, May 31 2012, Ralf Corsepius wrote:

> On 05/31/2012 12:45 PM, Pádraig Brady wrote:
>> On 05/31/2012 08:14 AM, Roberto Ragusa wrote:

>> Now /var/tmp should be "more persistent" which we don't need,
> Correct, using /var/tmp is wrong and a mistake.
>
> IMO, advising people to modify their code to using /var/tmp instead of
> /tmp is absurd and evidence of ignorance towards traditional use of
> /tmp and the FHS.

I couldn't say better.

>> So I'll patch sort to default to /var/tmp rather than /tmp.

Please don't.  As many pointed out, there are many disadvantages in
doing this, and I really do not think we should be "fixing" (sic) our
apps because of such a controversial feature.  `sort' and other programs
have been working right like this for *years*; introducing such change
would mean "please give me more bugs", as Ralf pointed out.

-- 
Sergio
--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

Chris Adams wrote:
> - Secure boot is required to be able to be disabled on x86 (the only
> platform Fedora will support it).

And this is exactly why we should just require our users to disable it!

I don't see any advantage at all from supporting this "feature", just 
problems:
* extra restrictions added to GRUB and the kernel to comply with the 
"security" (lockout) requirements. Even if they're all conditional on 
"secure" boot being enabled (are they really?), that still means extra code 
which can cause extra breakage even when running in normal mode (the one 
every Free Software user should be using).
* possible GPL violation. Did Red Hat Legal have a look at the plans 
already? Are they sure they're compliant with the GPL, v2 when it comes to 
the kernel, v3 when it comes to GRUB 2? (What's sure is that they aren't 
compliant with the spirit of the GPL, whatever version!)
* ineffectiveness of the added restrictions: Can't you still bring up a 
"Blue Pill" with a Window$ VM even with only unsigned userspace apps? And if 
we don't even allow those, where's the freedom?
* exercising your freedom to change the kernel (or even just to load an out-
of-tree module!) requires you to disable "Secure" (Restricted) Boot anyway, 
so why support the restricted mode? (As much as I hate proprietary drivers, 
you can definitely expect a horde of their users showing up at your door 
with a pitchfork…)
* implicit endorsement of M$ and their signature racket (including a 
monetary payment to their racketing partner Veri$ign – was that already 
made?). It might even lead M$ to drop the requirement to allow disabling 
"Secure" Boot (or even invert it into a prohibition as on ARM!), arguing 
that "Linux" (sic, should be GNU/Linux) supports it too anyway.

Re: *countable infinities only

On 05/31/2012 09:14 PM, Kevin Kofler wrote:
> Chris Adams wrote:
>> - Secure boot is required to be able to be disabled on x86 (the only
>> platform Fedora will support it).
> And this is exactly why we should just require our users to disable it!
>
> I don't see any advantage at all from supporting this "feature", just 
> problems:
> * extra restrictions added to GRUB and the kernel to comply with the 
> "security" (lockout) requirements. Even if they're all conditional on 
> "secure" boot being enabled (are they really?), that still means extra code 
> which can cause extra breakage even when running in normal mode (the one 
> every Free Software user should be using).
> * possible GPL violation. Did Red Hat Legal have a look at the plans 
> already? Are they sure they're compliant with the GPL, v2 when it comes to 
> the kernel, v3 when it comes to GRUB 2? (What's sure is that they aren't 
> compliant with the spirit of the GPL, whatever version!)
> * ineffectiveness of the added restrictions: Can't you still bring up a 
> "Blue Pill" with a Window$ VM even with only unsigned userspace apps? And if 
> we don't even allow those, where's the freedom?
> * exercising your freedom to change the kernel (or even just to load an out-
> of-tree module!) requires you to disable "Secure" (Restricted) Boot anyway, 
> so why support the restricted mode? (As much as I hate proprietary drivers, 
> you can definitely expect a horde of their users showing up at your door 
> with a pitchfork…)
> * implicit endorsement of M$ and their signature racket (including a 
> monetary payment to their racketing partner Veri$ign – was that already 
> made?). It might even lead M$ to drop the requirement to allow disabling 
> "Secure" Boot (or even invert it into a prohibition as on ARM!), arguing 
> that "Linux" (sic, should be GNU/Linux) supports it too anyway.

Re: [HEADS-UP] Rawhide: /tmp is now on tmpfs

On 06/01/2012 12:15 AM, Sergio Durigan Junior wrote:
> On Thursday, May 31 2012, Ralf Corsepius wrote:
> 
>> On 05/31/2012 12:45 PM, Pádraig Brady wrote:
>>> On 05/31/2012 08:14 AM, Roberto Ragusa wrote:
> 
>>> Now /var/tmp should be "more persistent" which we don't need,
>> Correct, using /var/tmp is wrong and a mistake.
>>
>> IMO, advising people to modify their code to using /var/tmp instead of
>> /tmp is absurd and evidence of ignorance towards traditional use of
>> /tmp and the FHS.
> 
> I couldn't say better.
> 
>>> So I'll patch sort to default to /var/tmp rather than /tmp.
> 
> Please don't.  As many pointed out, there are many disadvantages in
> doing this, and I really do not think we should be "fixing" (sic) our
> apps because of such a controversial feature.  `sort' and other programs
> have been working right like this for *years*; introducing such change
> would mean "please give me more bugs", as Ralf pointed out.

Well Ralf didn't impart any info as to why moving to /var/tmp would be a bug.
If it's a symlink to /tmp on older systems then there is no change.
But if the system /tmp is tmpfs then it would be a bug not to change,
which is the new default on debian IIUC.
BTW there is a long recent thread debian thread about the issues:
http://lists.debian.org/debian-devel/2012/05/thrd3.html#01092

Re: *countable infinities only

> What if anaconda was change to a license which required forks to
> certify and pay a one time $99 fee to some shell company, would anyone
> call Fedora still a free software distribution with a straight face?

Yes, if after paying $99 you are free to redistribute your own modified
versions.

By the way, I am assuming that you know that one can't modify Firefox and
redistribute it as Firefox without certification.

Happy hacking,
Debarshi

-- 
K&R is like the Bible. The fervent read it from end to end, the religious
keep a copy.  -- Arjun Shankar

--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Fedora remixes and Microsoft's secure booting crapola

--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

> This will exclude a whole class of usages that are currently available
> to Fedora users, such as the ReSpin projects that Fedora Unity used to
> produce from stock Fedora packages as well as any other downstream
> projects that build on Fedora.  This is not something affecting only a
> limit set of cases.  It's a major change to the ecosystem around Fedora.

So are you saying that Fedora Unity can not afford to pay $99? Or did I
misunderstand something?

> I'm not in a position at this point to provide a specific solution to
> this, but Windows 8 is not even out yet.  Fedora, Red Hat, and others

Unless you mention who "others" is/are, what you said means only Red Hat. 

Happy hacking,
Debarshi

-- 
K&R is like the Bible. The fervent read it from end to end, the religious
keep a copy.  -- Arjun Shankar

--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora remixes and Microsoft's secure booting crapola

On 05/31/2012 10:26 PM, Arun SAG wrote:
> I have been reading about secure boot. I understand that we are going 
> to pay Microsoft to get our keys signed. Will this change affect 
> people creating remixes?  What about kernel modules from third party 
> repositories like rpmfusion?  Will it be affected?
Not sure if you were subscribed to the list earlier, but there's a 
thread titled, "*countable infinities only" that discusses this exact 
point.  The link to the online archives is here:

https://lists.fedoraproject.org/pipermail/devel/2012-May/167605.html

(Note that the first e-mail in that archive somehow got corrupted when 
being archived.)

-- 
Libre Video
http://librevideo.org

--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: Fedora remixes and Microsoft's secure booting crapola

--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: *countable infinities only

On Fri, Jun 1, 2012 at 3:14 AM, Kevin Kofler <kevin.kofler <at> chello.at> wrote:
> Chris Adams wrote:
>> - Secure boot is required to be able to be disabled on x86 (the only
>> platform Fedora will support it).
>
> And this is exactly why we should just require our users to disable it!
>
> I don't see any advantage at all from supporting this "feature", just
> problems:

The advantages is that things just work (tm).
No one will stop you (or anyone else) from disabling it.
--

-- 
devel mailing list
devel <at> lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel