search for: horrifies

Hi all, We have a linux data server here, which used to be a workgroup member. Everything was fine then. Now we hav a new sbs server here, so the data server had to be made into a domain member. To do that i followed this manual. The thing is now, that the samba shares on the data server are slow as h**l What can be the problem ? Any ideas are welcome.... ! Code: [global]

https://bugzilla.netfilter.org/show_bug.cgi?id=991 Bug ID: 991 Summary: Exactly after 24h of uptime system hungs Product: netfilter/iptables Version: unspecified Hardware: sparc64 OS: Debian GNU/Linux Status: NEW Severity: blocker Priority: P5 Component: ip_tables (kernel)

On Thu, Jul 20, 2017 at 5:55 AM, Philipp Zabel <p.zabel at pengutronix.de> wrote: > Hi Thomas, > > On Thu, 2017-07-20 at 12:36 +0200, Thomas Petazzoni wrote: >> Hello, >> >> On Thu, 20 Jul 2017 11:36:55 +0200, Philipp Zabel wrote: >> >> > > I don't know if it has been discussed in the past, so forgive me if it >> > > has been. Have

Guys currently I am horrified by the ease at which I can find bugs in the pending paravirtualization patches. I have barely even looked at arch/i386 in the -mm tree and it feels like I am tripping over significant bugs left and right. Because no one has heeded my advice and put in a proper platform layer on arch/i386 and we are instead doing a half baked job with paravirt_ops it is still

Guys currently I am horrified by the ease at which I can find bugs in the pending paravirtualization patches. I have barely even looked at arch/i386 in the -mm tree and it feels like I am tripping over significant bugs left and right. Because no one has heeded my advice and put in a proper platform layer on arch/i386 and we are instead doing a half baked job with paravirt_ops it is still

Hi there, I manage a Samba installation which has been operating very well on Debian Wheezy for a number of years. Up until last week I was running 3.6.25, which (as always until now) I compiled myself. Because of the large number of changes in the recent security patches, I opted to try the Debian 'samba' and 'winbind' packages. I was a little horrified to find that Debian is

On Mar 22, 2010, at 1:27 PM, Charles Davis wrote: > Hi, > > I intend to participate in Google's Summer of Code this year, so I'd > like to bounce another idea around to see what you guys think. (I posted > a similar message to cfe-dev just now.) Be warned: this will shock you. > It may even horrify you. > > 1. Implement a 16-bit x86 backend. (*Chris recoils in

Oi. So. Now we have a version of windows that actually has legit uses for wine. Windows 7 can't run horrifyingly outdated 16bit programs(Such as Exile Escape from the Pit) period. Atleast so Ive herd--and tried and seen to seem to be true. Not to mention a multitude of programs that SHOULD run--but just dont like it(Worms Armageddon, for one... though dunno if it works on wine) Also.

Does anyone have a roadmap for MCJIT with what I think people are calling lazy compilation. Is this even on the cards? I spent the last few hours moving my project (extempore.moso.com.au) over to MCJIT (particularly for ARM), and am a little horrified to discover no ability to compile, and just as importantly to recompile, at a function level. This is absolutely mandatory for my project. I have

while finishing some work on the HAL integration (I'm now mapping DBus method with NUT commands, to allow at least the final UPS poweroff), I was horrified to realize (and so late) the changes in usbhid-ups->upsdrv_shutdown(). We've lost a lot there, but making a generic code, instead of keeping the subdrivers delegation. For example, the shutdown.return command (which is or should be

I'm not thinking of complicated cases. This happened to me in a function that returns 10 minute slots slot <- function (seconds) { return (seconds %/% 600) * 600 } Obviously I found the issue while debugging and corrected my code with surrounding parenthesis, but I was surprised that the R parser did not catch this syntactic error. This is especially poignant when we have to

Hi, I intend to participate in Google's Summer of Code this year, so I'd like to bounce another idea around to see what you guys think. (I posted a similar message to cfe-dev just now.) Be warned: this will shock you. It may even horrify you. 1. Implement a 16-bit x86 backend. (*Chris recoils in horror*) Yeah, I know 16-bit x86 is dead, but I find it interesting for historical purposes

Dear r-developers- After many years of using and coding in R and other languages, I came across something that I think should be flagged by the parser: bug <- function (x) { return (x + 1) * 1000 } > bug(1) [1] 2 The return() call is not like any other function call that returns a value to the point where it was called from. I think this should straightforwardly be handled in the

Hi Andrew, I was about to write a belated reply to this message (sorry for the delay), but then I realized that pretty much everything useful that I have to say on the subject is contained in this message (which is in a thread Albert Graef already linked to): https://groups.google.com/d/msg/llvm-dev/Rk9cWdRX0Wg/Fa1Mn6cyS9UJ Generally, I do hope that MCJIT will be capable of replacing the old

...stored procs. Seriously, I have nightmares about this database as well. But, I''ve been slogging away at it, and created a web app that''s impressed the bosses, and the vendor for that matter. But I also have nightmares about the fact that I don''t have a test suite. This horrifies me. What I''d like to do is test against the dev db, since if it gets horribly b0rked, I can restore from the previous night''s ComVault backup. I saw the suggestion to edit the rake task in the old rspec_on_rails plugin so that spec_prereq = :noop I was curious if there was a g...

I probably didn't follow the discussion of allowing "=" as an assignment operator closely enough, but I was a little bit horrified to discover today (using 1.6.0; I haven't upgraded to 1.6.1 yet) that x <- runif(20) y <- 1:20 y[x=min(x)] gives numeric(0) (because min(x) is non-integer). x <- sample(1:20,20,TRUE) y[x=min(x)] is even worse -- it gives the

FWIW, 'R CMD check --as-cran' in R-devel checks for "bogus return" statements but I think that's only for the case when one forgets the parentheses, e.g. 'return' instead of 'return()'. I don't think it catches this case but I'm also not sure. Though, I can imagine it might be possible to enhance the current check to include also this case. It could

>The use of R128 also raises the question about "REPLAYGAIN_REFERENCE_LOUDNESS" >tag. Currently flac/metaflac writes "REPLAYGAIN_REFERENCE_LOUDNESS=89.0 dB" >but doesn't use it when decoding (it seems that nothing uses this tag). >R128 defines reference level differently, so this tag makes little sense for >it. IMHO it's better not to write this tag when

I don't see how anything operating on the "result" of a return() call could be legal. The special semantics of the return() call is that it does **not** return control to the place it was called from, but rather to the location where its surrounding function(){} was called from. Mateo. -- Mateo Obreg?n. On Friday, 20 November 2020 22:52:58 GMT Duncan Murdoch wrote: > On

Thanks for the update Andy. I'm very happy to be involved in anyway that is helpful. If you would like me to test ideas, or contribute to further discussions, then please let me know. I currently have extempore running nicely with MCJIT for the "monolithic" case and am working on various LLVM hacks to better understand the issues involved with non-monolithic approaches - in