linux-kernel - Re: [GIT PULL] kdbus for 4.1-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 29 Apr 2015 17:18:28 -0700 (PDT)
From:	David Lang <david@...g.hm>
To:	Dave Airlie <airlied@...il.com>
cc:	"Theodore Ts'o" <tytso@....edu>, John Stoffel <john@...ffel.org>,
	Harald Hoyer <harald@...hat.com>,
	Richard Weinberger <richard.weinberger@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] kdbus for 4.1-rc1

On Thu, 30 Apr 2015, Dave Airlie wrote:

> On 30 April 2015 at 10:05, David Lang <david@...g.hm> wrote:
>> On Wed, 29 Apr 2015, Theodore Ts'o wrote:
>>
>>> On Wed, Apr 29, 2015 at 12:26:59PM -0400, John Stoffel wrote:
>>>>
>>>> If your customers wnat this feature, you're more than welcome to fork
>>>> the kernel and support it yourself.  Oh wait... Redhat does that
>>>> already.  So what's the problem?   Just put it into RHEL (which I use
>>>> I admit, along with Debian/Mint) and be done with it.
>>>
>>>
>>> Harald,
>>>
>>> If you make the RHEL initramfs harder to debug in the field, I will
>>> await the time when some Red Hat field engineers will need to do the
>>> same sort of thing I have had to do in the field, and be amused when
>>> they want to shake you very warmly by the throat.  :-)
>>>
>>> Seriously, keep things as simple as possible in the initramfs; don't
>>> use complicated bus protocols; that way lies madness.  Enterprise
>>> systems aren't constantly booting (or they shouldn't be, if your
>>> kernels are sufficiently reliable :-), so trying to optimize for an
>>> extra 2 or 3 seconds worth of boot time really, REALLY isn't worth it.
>>
>>
>> I've had Enterprise systems where I could hit power on two boxes, and finish
>> the OS install on one before the other has even finished POST and look for
>> the boot media. I did this 5 years ago, before the "let's speed up boot"
>> push started.
>>
>> Admittedly, this wasn't a stock distro boot/install, it was my own optimized
>> one, but it also wasn't as optimized and automated as it could have been
>> (several points where the installer needed to pick items from a menu and
>> enter values)
>>
>
> You guys might have missed this new industry trend, I think they call
> it virtualisation,
>
> I hear it's going to be big, you might want to look into it.

So what do you run your virtual machines on? you still have to put an OS on the 
hardware to support your VMs. Virtualization doesn't eliminate servers (as much 
as some cloud advocates like to claim it does)

And virtualization has overhead, sometimes very significant overhead, so it's 
not always the right answer.

David Lang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/