search for: futureproof

...l interface would be preferable, but it contains additional subsections - which are naturally represented by MCDataFragments - Is there an MC equivalent of a SubSection (which is-a Section so I can switch back and forth?) Currently we only have stuff that go into the File subsection only, but.. for futureproofing? I pretty much duplicated style from MCELFObjectWriter.cpp, which does muck with MCDataFragments - (in function WriteRelocation() around line 910 of MCELFObjectWriter.cpp )  I could not find an easier solution. The code currently closely tracks the layout required in the section, and its very s...

W dniu 20.08.2015 o 13:26, Mauricio Tavares pisze: > On Aug 20, 2015 6:54 AM, "ken" <gebser at mousecar.com> wrote: >> >> One of the build options for a laptop I'm looking at buying is DVD vs > Blu-Ray. I've never used Blue-ray before, so is there some compelling > reason, as a Linux guy, to want to get Blu-ray? > First of all, is this going

...erable, > but it contains additional subsections - which are naturally > represented by MCDataFragments - Is there an MC equivalent of a > SubSection (which is-a Section so I can switch back and forth?) > Currently we only have stuff that go into the File subsection only, > but.. for futureproofing? We cross that bridge when we get there. It might be that the best thing to do is organize the code so that we output the subsections in order. It might be to add some missing feature. For now using the regular streamer API will make this code a lot easier to read. > > -jason Cheers, R...

...ng that because of > the sheer capacity but my experience using DL DVDs for backup was not > as good as the original claims. Retention was not good after a year or > so, which led me to use hard drives instead with a slow rotation > policy and keeping hardware to read it (poor man's futureproofing). Well, retention was not an issue in my case (that were monthly backups, we didn't need to keep old backups). But eventually capacity became a problem. Recently we have switched to RDX. -- Over And Out MoonWolf

...ker myself, so I am not sure which is harder in terms of work to be done to develop and maintain the stuff - 2) is most likely harder from a communication/organizational point of view, and from the work to persuade the Release Managers to let such an additional Kernel package in. And 1) is the most futureproof thing to do, for sure. What I know is, it would be a pity and a loss for many users, and for the reputation of Debian not to ship Xen with Lenny. And I want to do everything I can to prevent that. So, what can be done to get this sorted - any ideas, and opinions what would be needed to do, and wh...

I''m trying to get some answers as to why I (my company actually) would go with RoR over TurboGears. The developer staff is fluent in both Ruby and Python so that is not an issue. Rails is well into its release cycle whereas Turbogears won''t be at 1.0 until later this week. They both do essentially the same thing and they both have cool features unique to themselves

...it contains additional subsections - which are naturally >> represented by MCDataFragments - Is there an MC equivalent of a >> SubSection (which is-a Section so I can switch back and forth?) >> Currently we only have stuff that go into the File subsection only, >> but.. for futureproofing? > > We cross that bridge when we get there. It might be that the best > thing to do is organize the code so that  we output the subsections in > order. It might be to add some missing feature. For now using the > regular streamer API will make this code a lot easier to read. Of...

...I thought about doing that because of the sheer capacity but my experience using DL DVDs for backup was not as good as the original claims. Retention was not good after a year or so, which led me to use hard drives instead with a slow rotation policy and keeping hardware to read it (poor man's futureproofing). > -- > Over And Out > MoonWolf > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos

...of >> the sheer capacity but my experience using DL DVDs for backup was not >> as good as the original claims. Retention was not good after a year or >> so, which led me to use hard drives instead with a slow rotation >> policy and keeping hardware to read it (poor man's futureproofing). > > Well, retention was not an issue in my case (that were monthly backups, > we didn't need to keep old backups). But eventually capacity became a > problem. Recently we have switched to RDX. > Which RDX? This: https://en.wikipedia.org/wiki/RDX ? Valeri +++++++++++++++...

...APIs > manage 64-bit handles, but other windows APIs return 32-bit int), so > 64-bit pid_t on mingw does seem to be a real concern. IIUC, POSIX says pid_t is a signed integer, but doesn't specify the size. Thus libvirt exposed pid_t as "signed long long" in our APIs to be futureproof. > > + > > +=head2 C<nbdkit_peer_uid> > > + > > +(nbdkit E<ge> 1.24) > > + > > + int nbdkit_peer_uid (void); > > + > > +Return the peer user ID. This is only available when the client > > +connected over a Unix domain socket, and o...

On 10/3/20 1:50 PM, Richard W.M. Jones wrote: > New nbdkit_peer_pid, nbdkit_peer_uid and nbdkit_peer_gid calls can be > used on Linux (only) to read the peer PID, UID and GID from clients > connected over a Unix domain socket. This can be used in the > preconnect phase to add additional filtering. > > One use for this is to add an extra layer of authentication for local >

...handles, but other windows APIs return 32-bit int), so > > 64-bit pid_t on mingw does seem to be a real concern. > > IIUC, POSIX says pid_t is a signed integer, but doesn't specify the > size. Thus libvirt exposed pid_t as "signed long long" in our APIs > to be futureproof. > > > > + > > > +=head2 C<nbdkit_peer_uid> > > > + > > > +(nbdkit E<ge> 1.24) > > > + > > > + int nbdkit_peer_uid (void); > > > + > > > +Return the peer user ID. This is only available when the client > &gt...

...to be virtualizable would need to > move to not using the sys::path functions that don't take a FileSystem > object. > You guys probably know more than I do about LLVM/Clang's needs wrt a file system cache, but apart from that, why not model according to the Boost implementation? Futureproof and *proven useful*. Ruben -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111206/ba489485/attachment.html>

...d<br> video keeps costs down by not needing to buy an additional card).<br> <br> Will I be able to RAID-Z my 5 HDDs into 1 pool and then somehow share that so<br> WinXP can see it? If so; what is the best/fastest way of doing it?<br> <br> I want this to be fairly futureproof. I am backing up a lot of history of my home<br> movies (roughly 500GB) that I want kept in uncompressed DV format. I can add<br> bigger/more HDDs later on when the prices drop. Also the ability to add more drives<br> to the pool also helps when I want to store my Mp3 and movie co...

...We only allow kernel to see SSE3, CMPXCHG16B and SSSE3 */ + *ecx &= 0x00002201; + /* Similarly: SSE, SSE2, FXSR, MMX, CMOV, CMPXCHG8B, FPU. */ + *edx &= 0x07808101; + /* Host wants to know when we flush kernel pages: set PGE. */ + *edx |= 0x00002000; + break; + case 0x80000000: + /* Futureproof this a little: if they ask how much extended + * processor information, limit it to known fields. */ + if (*eax > 0x80000008) + *eax = 0x80000008; + break; + } +} + +static unsigned long current_cr0, current_cr3; +static void lguest_write_cr0(unsigned long val) +{ + hcall(LHCALL_TS, val &a...

...We only allow kernel to see SSE3, CMPXCHG16B and SSSE3 */ + *ecx &= 0x00002201; + /* Similarly: SSE, SSE2, FXSR, MMX, CMOV, CMPXCHG8B, FPU. */ + *edx &= 0x07808101; + /* Host wants to know when we flush kernel pages: set PGE. */ + *edx |= 0x00002000; + break; + case 0x80000000: + /* Futureproof this a little: if they ask how much extended + * processor information, limit it to known fields. */ + if (*eax > 0x80000008) + *eax = 0x80000008; + break; + } +} + +static unsigned long current_cr0, current_cr3; +static void lguest_write_cr0(unsigned long val) +{ + hcall(LHCALL_TS, val &a...

As promised to Andrew, and with much thanks to Andi Kleen for feedback, this is the new series of lguest patches. Main change is the move to drivers/lguest (for future non-i386 expansion), but lots of cleanups driven by Andi's feedback and the documentation effort (which made me examine every line of code). It's not perfect, but it's definitely useful. Cheers, Rusty. List of

As promised to Andrew, and with much thanks to Andi Kleen for feedback, this is the new series of lguest patches. Main change is the move to drivers/lguest (for future non-i386 expansion), but lots of cleanups driven by Andi's feedback and the documentation effort (which made me examine every line of code). It's not perfect, but it's definitely useful. Cheers, Rusty. List of

On Tue, Dec 6, 2011 at 2:27 AM, Manuel Klimek <klimek at google.com> wrote: > On Tue, Dec 6, 2011 at 2:11 AM, Michael Spencer <bigcheesegs at gmail.com> wrote: >> On Sun, Dec 4, 2011 at 9:06 AM, Manuel Klimek <klimek at google.com> wrote: >>> On Sat, Dec 3, 2011 at 10:33 PM, Douglas Gregor <dgregor at apple.com> wrote: >>>> Hi Manuel,

On Tue, Dec 6, 2011 at 2:11 AM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Sun, Dec 4, 2011 at 9:06 AM, Manuel Klimek <klimek at google.com> wrote: >> On Sat, Dec 3, 2011 at 10:33 PM, Douglas Gregor <dgregor at apple.com> wrote: >>> Hi Manuel, >>> >>> On Nov 28, 2011, at 2:49 AM, Manuel Klimek wrote: >>> >>>>