OpenStack Users Updated Leads

2017-06-07 Thread Dena Rose 
Hi,

We have maintained verified opt-in business contacts of OpenStack users across 
the globe. Would you be interested in acquiring it to increase your customer 
base?

We can also provide you with similar technology users like:


  *   Amazon S3 users
  *   Microsoft Azure users
  *   Rackspace users
  *   CloudStack users
  *   Verizon Cloud users and more.

Let me know if you are interested in grabbing it so that we can connect and 
discuss more on this regarding counts and cost.

Regards,

Dena Rose
Online Marketing Manager

If you do not wish to receive future emails from us, please reply as 'leave out'

Re: DEP 15: Reserved namespace for DD-approved non-maintainer changes

2017-06-07 Thread Ian Jackson 
Sean Whitton writes ("DEP 15: Reserved namespace for DD-approved non-maintainer 
changes"):
> I am hereby reserving DEP number 15 for my draft DEP, "Reserved
> namespaces for DD-approved non-maintainer changes".
> 
> I'd like to suggest discussing this DEP on d-devel (which is the
> Reply-to for this e-mail).  The canonical DEP text is at
> .
> 
> The drivers are myself and Ian Jackson, who came up with the idea, but I
> said I'd write up the formal proposal.

Thanks, Sean.

For others: this was prompted by a conversation Sean and I had in a
pub on Monday.

Before we get into a detailed discussion here on -devel I think it
would be worth Sean and me getting the DEP draft into some kind of
reasonable shape that we both agree on.

So I won't reply in detail to the comments.

Ian.

Re: DEP 15: Reserved namespace for DD-approved non-maintainer changes

2017-06-07 Thread Boyuan Yang 
在 2017年6月7日星期三 +08 下午9:56:39，Sean Whitton 写道：
> Dear all,
> 
> I am hereby reserving DEP number 15 for my draft DEP, "Reserved
> namespaces for DD-approved non-maintainer changes".
> 
> I'd like to suggest discussing this DEP on d-devel (which is the
> Reply-to for this e-mail).  The canonical DEP text is at
> .
> 
> The drivers are myself and Ian Jackson, who came up with the idea, but I
> said I'd write up the formal proposal.

Just wondering why we need to control the branch name of proposed topic 
branch, or even use a single repo to receive contributions.

My thought is that all we need is the "Pull Request / Merge Request" feature 
on Alioth, where random contributors (who might have absolutely no permission 
anywhere) can create forks (forked repositories) freely and request for review 
and eventual merge from the forked repo into main repo if necessary. People 
are much familiar with such workflow similar to GitHub / GitLab's fork-and-
merge behaviour.

That would also be much easier than setting up custom access control rules 
based on permission inside a single repository.

--
Boyuan Yang

signature.asc
Description: This is a digitally signed message part.

DEP 15: Reserved namespace for DD-approved non-maintainer changes

2017-06-07 Thread Sean Whitton 
Dear all,

I am hereby reserving DEP number 15 for my draft DEP, "Reserved
namespaces for DD-approved non-maintainer changes".

I'd like to suggest discussing this DEP on d-devel (which is the
Reply-to for this e-mail).  The canonical DEP text is at
.

The drivers are myself and Ian Jackson, who came up with the idea, but I
said I'd write up the formal proposal.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Re: GitHub Open Source Survey 2017

2017-06-07 Thread Andrey Rahmatullin 
On Wed, Jun 07, 2017 at 04:57:17PM +0200, Adam Borowski wrote:
> I have yet to see a system vendor who issues BIOS/firmware updates at all
> after 1-2 years after manufacture.  If they don't sell the given piece of
> hardware anymore, there's no money to be made by keeping it updated.
> 
> And, even if they do issue such updates, they tend to be providen as Windows
> executables, which is unfun if you don't even have Windows on the machine in
> question.
FWIW my laptops and desktop MBs are usually updated with a flash tool
built into the BIOS setup interface with a file from a flash drive. But
it's a small sample, and, incidentally, my desktop got a
binary-file-with-a-windows-flasher "100 Series ME (Version 11.6.27.3264)
Update Tool" just two days ago (I didn't flash it yet).

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: GitHub Open Source Survey 2017

2017-06-07 Thread Adam Borowski 
On Wed, Jun 07, 2017 at 11:07:19AM -0300, Henrique de Moraes Holschuh wrote:
> On Wed, 07 Jun 2017, Christian Seiler wrote:
> > Am 2017-06-06 22:19, schrieb Adam Borowski:
> > >Or
> > >that you can sanely run x86 without at least {intel,amd64}-microcode.
> > 
> > Well, on some systems you can install BIOS/UEFI updates that will
> > load newer microcode very early in the boot process. In that case
> > you really don't need the {intel-amd64}-microcode packages, and
> > you could potentially run just Debian main without any non-free
> > software on the disk.
> 
> Provided that the system vendor issues timely updates and you check for
> new updates (and install them) frequently.

I thus prefer for someone to be [un]paid to do that work for me.

> And, unfortunately, even if you do, you could easily be still at risk:
> Too many system vendors are BAD at issuing regular firmware updates, and
> there are those that issue BIOS updates but stop updating the microcode
> inside.

I have yet to see a system vendor who issues BIOS/firmware updates at all
after 1-2 years after manufacture.  If they don't sell the given piece of
hardware anymore, there's no money to be made by keeping it updated.

And, even if they do issue such updates, they tend to be providen as Windows
executables, which is unfun if you don't even have Windows on the machine in
question.

> So, and I *am* sorry to say this, users in the general case *are* much
> better off with intel-microcode and amd64-microcode installed.

Why would this be a bad thing (beside needing non-free microcode at all)?
If I need to run non-free stuff, I prefer it to be where I can see it.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ A tit a day keeps the vet away.
⣾⠁⢰⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ (Rejoice as my small-animal-murder-machine got unbroken after
⠈⠳⣄ nearly two years of no catch!)

Re: GitHub Open Source Survey 2017

2017-06-07 Thread Henrique de Moraes Holschuh 
On Wed, 07 Jun 2017, Christian Seiler wrote:
> Am 2017-06-06 22:19, schrieb Adam Borowski:
> >Or
> >that you can sanely run x86 without at least {intel,amd64}-microcode.
> 
> Well, on some systems you can install BIOS/UEFI updates that will
> load newer microcode very early in the boot process. In that case
> you really don't need the {intel-amd64}-microcode packages, and
> you could potentially run just Debian main without any non-free
> software on the disk.

Provided that the system vendor issues timely updates and you check for
new updates (and install them) frequently.  That would be doing it
monthly or at most once every two months for recent systems...  All of
you, owners of Intel Skylake, Intel Kaby Lake, and AMD Ryzen systems,
are doing just that, aren't you?

Because if you aren't, you are at a much higher than usual risk of data
corruption and system misbehavior.

And, unfortunately, even if you do, you could easily be still at risk:
Too many system vendors are BAD at issuing regular firmware updates, and
there are those that issue BIOS updates but stop updating the microcode
inside.

So, and I *am* sorry to say this, users in the general case *are* much
better off with intel-microcode and amd64-microcode installed.

That would be the only reason I actually bother taking care of those two
packages: it is not like I get paid to do it, and it is not relevant to
my job either.  And it takes an annoying amount of effort to try to
track down what a microcode update might be fixing[1].


[1] only to find out it *is* indeed fixing critical defects, so you know
you will not be able to talk yourself out of doing the job when the next
update is released, either :-(

-- 
  Henrique Holschuh

Re: GitHub Open Source Survey 2017

2017-06-07 Thread Andrey Rahmatullin 
On Wed, Jun 07, 2017 at 01:49:54PM +0200, Christian Seiler wrote:
> > Or
> > that you can sanely run x86 without at least {intel,amd64}-microcode.
> 
> Well, on some systems you can install BIOS/UEFI updates that will
> load newer microcode very early in the boot process. In that case
> you really don't need the {intel-amd64}-microcode packages, and
> you could potentially run just Debian main without any non-free
> software on the disk.
But they are generally updated less often than the Debian packages.
Also, it's a good idea to think about the difference between a system with
the microcode updated by UEFI and one with the microcode updated by a
Debian package wrt open sourceness and such stuff.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: GitHub Open Source Survey 2017

2017-06-07 Thread Christian Seiler 

Am 2017-06-06 22:19, schrieb Adam Borowski:

Or
that you can sanely run x86 without at least {intel,amd64}-microcode.


Well, on some systems you can install BIOS/UEFI updates that will
load newer microcode very early in the boot process. In that case
you really don't need the {intel-amd64}-microcode packages, and
you could potentially run just Debian main without any non-free
software on the disk.

Regards,
Christian