yes, it was a lack of *any* notice; i occasionally check /n/sources/patch
for incoming patches and i don't believe the NSEC patch went through that
channel. in the past, changes that had a system-wide or kernel effect were
announce, and instructions for upgrading were given. certainly, it's not
req
my Plan 9 environment is the only one that i feel i know and have control
over; i don't feel the same about my (Canonical's) ubuntu desktop, my
(Google's) chromebook, my (Apple's) macbook, my (T-Mobile/Google's) android
phone, etc, etc, precisely because of auto-update. i appreciate that they
want
On May 20, 2014, at 11:41 AM, ron minnich wrote:
> This is not a human communication problem. It's a technology problem,
> trivially solved for many years now by many systems.
This event was a communication problem.
The technology, replica, works as advertised. In general it does
a very good
2014-05-20 15:30 GMT-04:00 erik quanstrom :
>> I can't think of any reason it should be implemented in that way as
>> long as the cache protocol has a total order (which it must given that
>> the μops that generate the cache coherency protocol traffic have a
>> total order), a state transition from
Quoting ron minnich :
Ah well, back to 'm' for this thread, and I now accept that this
community is unwilling to solve this simple problem, as so many others
have. Bummer.
ron
Deliberate misdirection then; got it.
I'm sorry you're sad, but comparing plan freaking 9 to an operating system
ba
On Tue May 20 15:50:56 EDT 2014, rminn...@gmail.com wrote:
> Ah well, back to 'm' for this thread, and I now accept that this
> community is unwilling to solve this simple problem, as so many others
> have. Bummer.
nobody said that. there's a difference between noting a strawman
argument, and po
Ah well, back to 'm' for this thread, and I now accept that this
community is unwilling to solve this simple problem, as so many others
have. Bummer.
ron
> I can't think of any reason it should be implemented in that way as
> long as the cache protocol has a total order (which it must given that
> the μops that generate the cache coherency protocol traffic have a
> total order), a state transition from X to E can be done in a bounded
> number of cyc
2014-05-20 11:41 GMT-04:00 erik quanstrom :
>> Dunno what to say. I'm not trying this on Plan 9, and I can't
>> reproduce your results on an i7 or an e5-2690. I'm certainly not
>> claiming that all pipelines, processors, and caches are equal, but
>> I've simply never seen this behavior. I also can'
Quoting ron minnich :
I have a different perspective. There are millions of chromebooks out
there updating all the time, from the firmware to the kernel to the
root file system to everything. It all works.
Millions of carefully-crafted machines updating all the time, from the
firmware
to th
> I never understood why binaries are pulled. Even on a lowly
> RPi it takes 4 minutes to build everything (half if you cut
> out gs). And the 386 binaries are useless on non-386
> platforms!
>
> Why not just separate binary and source distributions? Then
> include a file in the source distributi
On Tue May 20 12:42:35 EDT 2014, rminn...@gmail.com wrote:
> I have a different perspective. There are millions of chromebooks out
> there updating all the time, from the firmware to the kernel to the
> root file system to everything. It all works.
>
> If you are telling me that the upgrade techno
On Mon, 19 May 2014 17:34:24 EDT Anthony Sorace wrote:
>
> Ron wrote:
>
> > That said, the problems were due (IMHO) to a limitation in the
> > update mechanism, not to the inclusion of a new system call.
>
> This is true depending on how you define "update mechanism".
> A simple note from whoev
I have a different perspective. There are millions of chromebooks out
there updating all the time, from the firmware to the kernel to the
root file system to everything. It all works.
If you are telling me that the upgrade technology of Plan 9 can not
handle an automatic upgrade, fine; we have the
> Dunno what to say. I'm not trying this on Plan 9, and I can't
> reproduce your results on an i7 or an e5-2690. I'm certainly not
> claiming that all pipelines, processors, and caches are equal, but
> I've simply never seen this behavior. I also can't think of an
> application in which one would w
2014-05-19 22:12 GMT-04:00 erik quanstrom :
> i get a 126% difference executing lock xadd 1024*1024 times
> with no branches using cores 4-7 of a xeon e3-1230. i'm sure it would
> be quite a bit more impressive if it were a bit easier to turn the timer
> interrupt off.
Dunno what to say. I'm not
> > That said, the problems were due (IMHO) to a limitation in the
> > update mechanism, not to the inclusion of a new system call.
>
> This is true depending on how you define "update mechanism".
> A simple note from whoever made the decision to push the
> change out to the effect of "hey, we're
Ron wrote:
> That said, the problems were due (IMHO) to a limitation in the
> update mechanism, not to the inclusion of a new system call.
This is true depending on how you define "update mechanism".
A simple note from whoever made the decision to push the
change out to the effect of "hey, we're
18 matches
Mail list logo