search for: sympathi

On Thu, Jul 13, 2023 at 9:04?AM Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de> wrote: > > hello Sean, > > On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote: > > I'd really prefer this patch (series or single) is not accepted. This > > will cause problems for everyone cherry-picking patches to a > > downstream kernel (LTS or distro tree). I

On Thu, Jul 13, 2023 at 9:04?AM Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de> wrote: > > hello Sean, > > On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote: > > I'd really prefer this patch (series or single) is not accepted. This > > will cause problems for everyone cherry-picking patches to a > > downstream kernel (LTS or distro tree). I

Ok, believe it or not, I've looked through all 209 pages of the Samba-HOWTO_Collection.pdf plus used this mail list and other internet sources, used those recommendations, tried almost every possible iteration on the samba.conf file, looked at logs until nauseated and have concluded that there is no way that Windows ME can connect to a Linux box using Samba. Connecting to the WinME box from

On 13/07/2023 16:09, Thomas Zimmermann wrote: > Hi > > Am 13.07.23 um 16:41 schrieb Sean Paul: >> On Thu, Jul 13, 2023 at 9:04?AM Uwe Kleine-K?nig >> <u.kleine-koenig at pengutronix.de> wrote: >>> >>> hello Sean, >>> >>> On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote: >>>> I'd really prefer this patch

On 13/07/2023 16:09, Thomas Zimmermann wrote: > Hi > > Am 13.07.23 um 16:41 schrieb Sean Paul: >> On Thu, Jul 13, 2023 at 9:04?AM Uwe Kleine-K?nig >> <u.kleine-koenig at pengutronix.de> wrote: >>> >>> hello Sean, >>> >>> On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote: >>>> I'd really prefer this patch

hello Sean, On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote: > I'd really prefer this patch (series or single) is not accepted. This > will cause problems for everyone cherry-picking patches to a > downstream kernel (LTS or distro tree). I usually wouldn't expect > sympathy here, but the questionable benefit does not outweigh the cost > IM[biased]O. I agree that

hello Sean, On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote: > I'd really prefer this patch (series or single) is not accepted. This > will cause problems for everyone cherry-picking patches to a > downstream kernel (LTS or distro tree). I usually wouldn't expect > sympathy here, but the questionable benefit does not outweigh the cost > IM[biased]O. I agree that

The marilith boxes use a conserver (http://www.conserver.com/) setup for serial access. Our installation exports the logs via http allowing us to grab them with wget. Sending debug keys with is handled separately via xenuse. xenuse ultimately speaks to the conserver too but it abstracts away the IP and port to use so this is preferred. With these changes the correct Serial hostprop for a

On Wed, Jul 12, 2023 at 10:52?AM Jani Nikula <jani.nikula at intel.com> wrote: > > On Wed, 12 Jul 2023, Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de> wrote: > > Hello, > > > > while I debugged an issue in the imx-lcdc driver I was constantly > > irritated about struct drm_device pointer variables being named "dev" > > because with

On Wed, Jul 12, 2023 at 10:52?AM Jani Nikula <jani.nikula at intel.com> wrote: > > On Wed, 12 Jul 2023, Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de> wrote: > > Hello, > > > > while I debugged an issue in the imx-lcdc driver I was constantly > > irritated about struct drm_device pointer variables being named "dev" > > because with

"Michael S. Tsirkin" <mst at redhat.com> writes: > On Thu, Jul 04, 2013 at 10:49:42AM +0300, Michael S. Tsirkin wrote: >> > case). >> > >> > Regrettably, initial driver implementations used simple layouts >> > and devices came to rely on it, despite this specification >> > wording. It is thus recommended that drivers be conservative

"Michael S. Tsirkin" <mst at redhat.com> writes: > On Thu, Jul 04, 2013 at 10:49:42AM +0300, Michael S. Tsirkin wrote: >> > case). >> > >> > Regrettably, initial driver implementations used simple layouts >> > and devices came to rely on it, despite this specification >> > wording. It is thus recommended that drivers be conservative

On Tue, Jul 02, 2013 at 03:34:09PM +0930, Rusty Russell wrote: > Paolo Bonzini <pbonzini at redhat.com> writes: > > Il 01/07/2013 01:47, Rusty Russell ha scritto: > >> > > > >> > > Mainly because I'm not sure that *all* devices are now safe. Are they? > >> > > >> > virtio-scsi's implementation in QEMU is not safe (been

On Tue, Jul 02, 2013 at 03:34:09PM +0930, Rusty Russell wrote: > Paolo Bonzini <pbonzini at redhat.com> writes: > > Il 01/07/2013 01:47, Rusty Russell ha scritto: > >> > > > >> > > Mainly because I'm not sure that *all* devices are now safe. Are they? > >> > > >> > virtio-scsi's implementation in QEMU is not safe (been

On Fri, 2014-09-26 at 12:09 -0400, Stephen Canon wrote: > > On Sep 26, 2014, at 11:59 AM, Tim Northover <t.p.northover at gmail.com> wrote: > > > >> I know it's part of test-suite/external, but this constant fold code has > >> been around 5+ years. Was the bug lying dormant all this time, only visible > >> on PPC, or something else? > > >

Hello! Disapointed about SPSS I have to choose another statistic program. And altough I sympathise with the idea of a non-commercial software-project like R and I like the spirit of the R community (and of course I am not keen on paying 150$ to SAS for a one-year students license), I will probably buy SAS, because people I will work with use SAS and I want a close cooperation with them. Beside...

Hi Jack, > IMHO, the more important thing is to fish out the remaining regressions > in the llvm vectorization code by defaulting -fplugin-arg-dragonegg-enable-gcc-optzns > on in dragonegg svn once llvm 3.0 has branched. Hopefully this will get us wider > testing of the llvm vectorization support and some additional smaller test cases > that expose the remaining bugs in that

On Wed, 12 Jul 2023, Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de> wrote: > Hello, > > while I debugged an issue in the imx-lcdc driver I was constantly > irritated about struct drm_device pointer variables being named "dev" > because with that name I usually expect a struct device pointer. > > I think there is a big benefit when these are all renamed to

On Wed, 12 Jul 2023, Uwe Kleine-K?nig <u.kleine-koenig at pengutronix.de> wrote: > Hello, > > while I debugged an issue in the imx-lcdc driver I was constantly > irritated about struct drm_device pointer variables being named "dev" > because with that name I usually expect a struct device pointer. > > I think there is a big benefit when these are all renamed to

Hi All, Some of the discussion recently has touched on ripping one's own CDs for archival purposes. I've consistantly rejected the idea of doing this in my case for space and time reasons, and in the belief that commercially produced CDs when properly treated can be expected to have a very long life. However, I'm now questioning this assumption. I have a 2 CD set of "The