plan9 also has /n/dump, which is great to find out if
and when suff has regressed. :)
having self contained program binaries is great.
--
cinap
> Well, you know there is a lot of noise for linux kernel about keeping it
> compatible for even very old versions of apps binaries, while in
> reality, linux apps binaries are very rare to be executed even from one
> distro to another...
most of the 2ed binaries still run on modern 386 kernels.
(
> that, and they gave up on being compatable with apple's webkit.
It's not just about compatibility: they shrunk the scope of the
problem they're trying to solve by quite a bit. WebKit aims to be a
sort of general-purpose web rendering engine; Blink (Google's
fork) is much more closely targeting C
On 05/06/2014 05:24 PM, Aram Hăvărneanu wrote:
> The question is not why does Plan 9 compile so quickly, is what
> catastrophe happened in Unix making everything so slow and large.
Well, you know there is a lot of noise for linux kernel about keeping it
compatible for even very old versions of app
Plan 9 compilers are fast, Unix compilers are slow. Plan 9 compilers
compile less because the philosophy regarding #include files is
different. Plan 9 programs (including the kernel) are small, Unix
programs are large.
The Plan 9 kernel has less lines of code than Unix configure scripts.
The quest
> Recently I saw that the source of the underlying engine for (I think)
> Chrome had roughly halved in size. I'm not sure if that's the same
> version as the you've got. They'd done trendy things like devise and
> implement suitable abstractions for different parts of the
> graphics/browsing mode
On Tue May 6 04:39:11 EDT 2014, arn...@skeeve.com wrote:
> > also, quite a bit that is unaccountably still in other kernels ("because
> > Unix did it exactly that way in the 1970s on a PDP-11")
>
> I think that "unaccountably" is a bit harsh. There is A L O T of old
> Unix software that still ju
On 6 May 2014 10:52, wrote:
> like systems, one may not be even able to link the thing.
Recently I saw that the source of the underlying engine for (I think)
Chrome had roughly
halved in size. I'm not sure if that's the same version as the you've got.
They'd done trendy things like devise and i
On Tue, May 06, 2014 at 11:39:03AM +0200, tlaro...@polynum.com wrote:
>
> On Tue, May 06, 2014 at 09:02:21AM +0100, Charles Forsyth wrote:
> > On 6 May 2014 03:19, Charles Forsyth wrote:
> >
> > Of course, that's balanced
> > by browsers now easily rivalling the kernels you mention for complexit
On Tue, May 06, 2014 at 09:02:21AM +0100, Charles Forsyth wrote:
> On 6 May 2014 03:19, Charles Forsyth wrote:
>
> Of course, that's balanced
> by browsers now easily rivalling the kernels you mention for complexity and
> certainly size, with their brutalist programming architectures.
And it is
Charles Forsyth wrote:
> On 6 May 2014 09:38, wrote:
>
> > I think that "unaccountably" is a bit harsh.
>
>
> I was talking about kernels and kernel mechanisms.
Fair enough then.
Thanks,
Arnold
On 6 May 2014 09:38, wrote:
> I think that "unaccountably" is a bit harsh.
I was talking about kernels and kernel mechanisms.
> also, quite a bit that is unaccountably still in other kernels ("because
> Unix did it exactly that way in the 1970s on a PDP-11")
I think that "unaccountably" is a bit harsh. There is A L O T of old
Unix software that still just compiles and works out of the box on
Linux, Solaris, *BSD. There
On 6 May 2014 03:19, Charles Forsyth wrote:
> the kernel source is less than the size of their include files
also, quite a bit that is unaccountably still in other kernels ("because
Unix did it exactly that way in the 1970s on a PDP-11")
is in user space or across a network in Plan 9. of course
> 2014-05-05 22:19 GMT-04:00 Charles Forsyth :
> > On 6 May 2014 03:13, yan cui wrote:
> >
> >> Instead of digging much into the kernel code, I post the question here.
> >> Does the speed come from its good design or insufficient kernel support?
> >
> > it's a bit of both: the compiler suite is mu
Thanks Charles for the quick reply! It is really interesting.
Believe I can find more interesting things after digging deeper.
Yan
2014-05-05 22:19 GMT-04:00 Charles Forsyth :
>
> On 6 May 2014 03:13, yan cui wrote:
>
>> Instead of digging much into the kernel code, I post the question here
On 6 May 2014 03:13, yan cui wrote:
> Instead of digging much into the kernel code, I post the question here.
> Does the speed come from its good design or insufficient kernel support?
it's a bit of both: the compiler suite is much faster; the kernel source is
less than the size of their includ
17 matches
Mail list logo
