search for: unspeakably

On Tue, Mar 03, 2020 at 01:19:22PM -0800, Kees Cook wrote: > On Tue, Mar 03, 2020 at 01:01:26PM -0800, Kristen Carlson Accardi wrote: > > On Tue, 2020-03-03 at 07:43 -0800, Thomas Garnier wrote: > > > On Tue, Mar 3, 2020 at 1:55 AM Peter Zijlstra <peterz at infradead.org> > > > > But,... do we still need this in the light of that fine-grained > > >

On Tue, Mar 03, 2020 at 01:19:22PM -0800, Kees Cook wrote: > On Tue, Mar 03, 2020 at 01:01:26PM -0800, Kristen Carlson Accardi wrote: > > On Tue, 2020-03-03 at 07:43 -0800, Thomas Garnier wrote: > > > On Tue, Mar 3, 2020 at 1:55 AM Peter Zijlstra <peterz at infradead.org> > > > > But,... do we still need this in the light of that fine-grained > > >

On 2020-03-04 10:21, Kees Cook wrote: > On Wed, Mar 04, 2020 at 10:21:36AM +0100, Peter Zijlstra wrote: >> But at what cost; it does unspeakable ugly to the asm. And didn't a >> kernel compiled with the extended PIE range produce a measurably slower >> kernel due to all the ugly? > > Was that true? I thought the final results were a wash and that earlier >

On 2020-03-04 10:21, Kees Cook wrote: > On Wed, Mar 04, 2020 at 10:21:36AM +0100, Peter Zijlstra wrote: >> But at what cost; it does unspeakable ugly to the asm. And didn't a >> kernel compiled with the extended PIE range produce a measurably slower >> kernel due to all the ugly? > > Was that true? I thought the final results were a wash and that earlier >

Hi- One last question for the week, I promise. I''ve got one IP ProxyArp''d according to the instructions at http://www.shorewall.net/ProxyARP.htm. I''ve setup the shorewall/proxyarp file as follows: #ADDRESS INTERFACE EXTERNAL HAVEROUTE PERSISTENT 208.4.145.73 br0 eth1 no yes #LAST LINE -- ADD YOUR ENTRIES

On 10/10/2017 09:53 AM, KM wrote: > Thanks for all of the input, not really sure what if anything I will do.? i was hoping it would be easy and i could just create a /boot in root, and copy the actual boot contents to it and use it.?? wishful thinking i guess.? just to give a complete picture here is the current partitioning on the server....in case anyone wants to say anymore.? Thanks in

...* i32, the ByValSize and ByValAlign if it was a byval pointer: e.g. "{float, float}* byval". Even in the first case there's no indication of where a composite type begins and ends. The latter could be bludgeoned to mean "this is an HFA, put it in VFP regs", but it would be unspeakably ugly. I believe that if the LLVM original Type* pointer is exposed to TargetLowering (perhaps as part of InputArg/OutputArg), then LLVM itself can decide what to do with both Small Structures and HFAs in a sane manner: writing a front-end which adheres to the PCS would be much easier for any sourc...

First, as I'm here and owe it: huge thanks to Dirk and others who maintain the Debian packaging. Second: I realise these questions are not right on topic here and I will go to the rstudio community support next but I'm failing to find answers elsewhere on the web which makes me suspect they haven't come up there and might well be Debian specific so I suspect that if the expertise

On Wed, Mar 04, 2020 at 10:21:36AM +0100, Peter Zijlstra wrote: > But at what cost; it does unspeakable ugly to the asm. And didn't a > kernel compiled with the extended PIE range produce a measurably slower > kernel due to all the ugly? Was that true? I thought the final results were a wash and that earlier benchmarks weren't accurate for some reason? I can't find the thread

Chris, I fear you may be overcomplicating things. RStudio tends to just work; the .deb files are also large and "mostly self-contained" -- so that generally only require one or two other packages you should find without trouble. Of course I cannot fully speak to your experience as I do not run Debian stable (mostly current Debian (ie "testing") or Ubuntu (ie now 18.10) for

I've done the unspeakable. I took a working setup of 1.0.5 and upgraded with the latest cvs. with 1.0.5 distinctive ring worked great. with the latest cvs, it doesn't seem to work with my sipura 2000 (the only thing i have to test it with). I can see in console that its sending the info, but its not working? i realize the likely hood is I messed something up somehow during checkout or

Ian Leonard wrote: > >> If I use smbmount and copy a 180k file, it transfers in about 0 seconds > >> (including unmounting). > >> > >> If I use smbclient and 'put' the file, it takes 14 seconds. I have heard > >> of an MTU problem but can't see any configuration options. Ian then experimented with the buffer-size option of smbclient, and

On 10/10/2017 09:20 PM, Robert Nichols wrote: > For you, there really is no way around the messy and delicate process > of shrinking and relocating a filesystem and the LVM volumes to make > space for a larger /boot partition. Frankly, I would hesitate to do > that in place on my own system, and I have quite a bit of experience > with doing unspeakable things with LVM volumes.

On Wed, Mar 4, 2020 at 10:45 AM H. Peter Anvin <hpa at zytor.com> wrote: > > On 2020-03-04 10:21, Kees Cook wrote: > > On Wed, Mar 04, 2020 at 10:21:36AM +0100, Peter Zijlstra wrote: > >> But at what cost; it does unspeakable ugly to the asm. And didn't a > >> kernel compiled with the extended PIE range produce a measurably slower > >> kernel due to

--- Matt Zimmerman <mdz@debian.org> wrote: > The only difference in the command lines seems to be that your > xmms-config > explicitly links with -lgthread, while I suppose mine lets the > dynamic linker > pull it in. The only significant difference between the old and new > _LIBADD > lines is that @XMMS_LIBS@ is at the beginning in the new one. Now > that I think

...* i32, the ByValSize and ByValAlign if it was a byval pointer: e.g. "{float, float}* byval". Even in the first case there's no indication of where a composite type begins and ends. The latter could be bludgeoned to mean "this is an HFA, put it in VFP regs", but it would be unspeakably ugly. I believe that if the LLVM original Type* pointer is exposed to TargetLowering (perhaps as part of InputArg/OutputArg), then LLVM itself can decide what to do with both Small Structures and HFAs in a sane manner: writing a front-end which adheres to the PCS would be much easier for any sourc...

On Tue, Oct 10, 2017 at 10:36:16AM -0400, Stephen John Smoogen wrote: > On 10 October 2017 at 09:55, KM <info4km at yahoo.com> wrote: > > First off - let me say I am not an administrator. I need to know if there is an easy way to increase my /boot partition. When I installed CentOS 6 after running 5, it was my oversight not to increase the /boot size. it's too small and I

I''d like to be able to use a CD drive on the Dom0 to be accessible on the DomU systems. I do see some notes involving cdrom drives in the Xen 3.1 Enterprise notes, and in the VT notes, but not for systems without that on-board virtualization feature. And the syntax of the cdrom command options are documented nowhere in 3.0.3. I found completely useless notes at

Thanks Dirk, I wonder if I'm hitting problems you're not seeing not only because of running stretch/stable but also because of running the i386 version. I suspect most people are on 64 bit systems now. Anyway, I have managed to install Rstudio OK by going up to stretch-cran35. Rstudio wouldn't install from there: root at Toshiba-L750-Stretchi386:/etc/apt# apt-get install rstudio

On Thu, Feb 27, 2020 at 04:00:45PM -0800, Thomas Garnier wrote: > Minor changes based on feedback and rebase from v10. > > Splitting the previous serie in two. This part contains assembly code > changes required for PIE but without any direct dependencies with the > rest of the patchset. > > Note: Using objtool to detect non-compliant PIE relocations is not yet > possible