Well, no, not really. Google cannot disable a program at all. All they can do is disable a distribution channel for it. In my mind, that's quite an important difference.
The difference is important because it does not affect Android as a platform at all. It only affects Google's app store. I can understand someone refusing to use Google's app store over this issue, but not anyone refusing to use Android.
(In fact, though, that last sentence shouldn't be said unrestricted. If it happens such that Android has some built-in, mandatory DRM scheme that is used for this kill-switch, that may be reason enough to hate Android.)
It may sound remote, but you may want to try RTFA:ing. I know it's not going to happen, though, so I'll summarize why it's OK for Google.:)
The thing is that Android allows for installing programs from -- hear and be astonished! -- other sources than Google itself, unlike Apple. Without any extra or undue inconvenience.
And, Android's kill switch is only for the programs that come through Google's own app store. So, you can probably pretty much bet that it's only going to be used to regulate malware, or Google's app store won't last long. Or if Google does misuse it, you'll just have to download the program in question directly from its developer.
It may sound remote, but you may want to try RTFA:ing. I know it's not going to happen, though, so I'll summarize why it's OK for Google.:)
The thing is that Android allows for installing programs from -- hear and be astonished! -- other sources than Google itself, unlike Apple. Without any extra or undue inconvenience.
And, Android's kill switch is only for the programs that come through Google's own app store. So, you can probably pretty much bet that it's only going to be used to regulate malware, or Google's app store won't last long. Or if Google does misuse it, you'll just have to download the program in question directly from its developer.
I could not agree more, and none to my surprise, TFA was full of inflated fluff and very little substance. It was hard enough to wade through it even to find anything substantial at all, but let me highlight some of the things that can be found:
In fact, many developers would rather be freed from the hassles imposed by traditional systems programming languages. VM-based languages offer such features as automatic garbage collection, runtime bytecode verification, and security sandboxes -- all of which translate into peace of mind.
Of course garbage collection has been a feature of LISP since its inception, which has been compilable to machine code since... the 60s? Not to mention the garbage collection libraries available for C and other languages. I'd care to call that point bogus.
Likewise, runtime bytecode verification isn't necessary with a hardware CPU. It's just made to ensure that a JVM doesn't encounter any illegal instructions or jump to code outside the current protection domain. Hardware CPUs can do illegal instruction checking in parellel with execution without penalties, and virtual memory makes the jump checks pointless as well. Not to mention that it is less restricted, so that one can implement such things as tail-call optimization or continuations without reimplementing the CPU.
Oh, and of course, operating systems have had security sandboxes called "processes" since... the 60s? Of course, one could well argue that it would be swell to be able to further control a process' privileges to a degree not available on, say, Linux or NT, but that isn't exactly something that requires a VM.
Dynamic languages, on the other hand, mean efficient coding; their high-level syntax makes it easy to conceptualize applications and build prototypes rapidly.
Yeah. But as Lisp, Psycho and countless others have demonstrated, they don't need a VM to run efficiently.
The great advantage of a generic VM, as opposed to a language-specific one, is flexibility.
Of course, exactly what a "generic" VM entails does not seem to be entirely clear to the author. Or at least, I can't find anything about it in TFA.
Oh, I take that back. My bad. I read that "Mozilla Firefox", rather that "Mobile Firefox", as it actually said. It might still be arguable that "Mobile Gecko" would be a lot more accurate, though.
That's some typo in the headline. Or at least, I'm assuming that it's supposed to be "Fennec", and not "Firefox". I'm a bit impressed that that got through.
Oh, but you couldn't beat him in a hipness contest, you vile non-Mac user.;)
To get back on track, though, the parent's point wasn't really to never have to turn the notebook off, but merely that such features as sleep-to-RAM and hibernation pretty much negates the usefulness of an "instant on" system like the one in TFA.
It's one thing to have to reboot every once in a blue moon due to a kernel update (though I might suggest that you look into Debian stable if you are disturbed by frequency of updates;) or hardware upgrades, but I'd be able to bet a lot that's not really the kind of opportunity that one would use an "instant on" system anyways. When you run into a low battery or even when switching OSes, you can just hibernate.
If anything, I for one would appreciate a coreboot-compatible notebook computer, since the BIOS seems to be what takes the longest time to get through when going back from hibernation. But that would most likely apply to the "instant on" system as well.
But will Windows 7 really have kernel version 6.1? Correct me if I'm wrong (I don't use Windows, after all), but isn't NT 6.1 used for Windows Server 2008? As I know it, the kernel versions line up with release versions as follows:
NT 3.something: Initial NT release with the version number written to match the non-NT Windows 3.x releases.
NT 4.x: The various versions of NT4.
NT 5.0: Windows 2000
NT 5.1: Windows XP
NT 5.2: Windows Server 2003
NT 6.0: Windows Vista
NT 6.1: Windows Server 2008
If I'm not terribly mistaken somewhere along those lines, it would seem to make sense if the next release of Windows (that is, Windows 7) would use kernel version 7.0.
I'd like to see some citation for the fact that Windows 7 would use NT 6.1. It might make sense if that shows in current test builds or leaked screen shots or something, since they probably just haven't increased the version number internally yet.
It also begs the question how this speed-up relates to the usage of non-PSK WPA. I can't say I know by heart how WPA key initialization works in 802.1X-authenticated networks, but I'm pretty sure it uses different keys for each session, unlike PSK.
Although, like someone else pointed out, it doesn't seem like a good idea to rely on WPA alone to protect sensitive information anyway. If one really wants the information to be left alone, it should have been encrypted end-to-end using TLS from the start.
Then again, CA-signed certificates also suck. I've already written about it here, so I won't reformulate the problem in this post, but I'll quote the most relevant part:
---
The problem, then, is that this implies that you need to trust
Verisign and Thawte to properly validate all the certificate requests
that they get—people in an extremely large, bureaucratically
weighed-down enterprise that process thousands of certificates daily
using automated processes. What are the chances that they wouldn't let
one single mistake slip through, and issue a certificate to a
cracker for a site that he does not own? The problem does not end
there, however: The certificates pre-installed on new PCs are not
limited to Verisign and Thawte. They commonly ship with the
certificates of around 50 different certificates organizations. Even
if you feel secure in trusting Verisign and Thawte (which you should
not, but more on that later), what are the chances that all
of these can be trusted to consist entirely of incorruptible people
and flawless processes? And, even if they did, what are the chances
that all of them are completely secure and cannot themselves be cracked
to produce faux certificates? For this reason alone, I, for one, would
consider the entire process flawed and untrustworthy, and I would
implore you to do the same. Therefore, Haven and Hearth uses its
own, self-signed SSL certificate, bypassing the certificate
authorities. To further clarify our stance, the following three points
of policy are noteworthy:
I do not want to convince you to distrust people. This is a
problem of statistics; it would be almost weird if, somewhere in any
of the many organizations whose certificates are installed in browsers
worldwide, there did not exist anyone who was untrustworthy
or just one computer system which is crackable, and the
system is designed in such a way that just one is enough to break
it.
Sure enough, there have not been many major security breaches through
this route (though it is not unheard of, either), so you might think
that I am merely being alarmist, but I would still argue that the
flaws in the system is enough reason to boycott it.
Last, but not least: As I mentioned above, the certificate
authorities more often than not charge quite obscene amounts for their
services, which emanates an attitude that "The web is for
corporations, not for individuals"; a statement that we resent.
But hold on, there is more to this. You may have read the preceding
paragraph and still thought it all right to trust all these diverse
organizations. However, you really should not: it is
well documented that Verisign actively produces faux certificates
for various purposes, especially for law enforcement agencies, so that
they can perform MITM attacks. You can see
Verisign's own home page if you doubt it. What Verisign's
faux certificates mean in practice, is that their holder can
impersonate any web site, to listen to the traffic
between them and their visitors, modify their content arbitrarily and
catch any and all sensitive information. And by that, I really mean
any web site, not only those with certificates signed by
Verisign in the first place. See, when the browser performs its
certificate authenticity check, it checks the web site's certificate
against any of its installed certificate authorities, and it does not
even warn you if the web site's certificate has changed since the last
time you visited it, as long as it is signed by just one of the
certificate authorities it knows of. Of course, it is not only
Verisign which is bestowed with this power – any of the
certificate authorities can do th
Actually though, the 4 GB limitation is the virtual address space size. Most 686-class CPUs have a 36-bit address bus and PAE extensions for up to 64 billion physical addresses. (For the uninformated, PAE allows setting the high 4 bits of the address bus in the page tables).
It doesn't mention Vista specifically, but it does list different physical address space limitation for the various editions of other Windows versions. Among others, XP is mentioned as being limited to 4 GB of physical address space, and I'd guess the cause of that would be its not being licensed for more than that. By similar reasoning, it wouldn't surprise me if most editions of Vista have the same limitation. I guess that's what you get for using evilware.
Honestly, why does the 2x RAM guideline make any sense?
It doesn't, and I'm surprised and chocked to see that noone here on Slashdot has posted the reason yet.
The reason why twice as much swap as RAM is commonly recommended is because an ancient Linux swap implementation (I don't know exactly when) was optimized that way. When there was twice as much swap as RAM, it performed the best. It has not been that way for years, though, so that recommendation is simply obsolete.
When you create your swap space today, you should simply be considering how much total virtual memory you want. Nothing more and nothing less.
In all honesty, though, what makes you think that the disagree mail posts are about making light of the senders?
Studying other people, their opinions, reactions and language is a basic part of human behavior, wouldn't you agree? The further from oneself the objects of the study are, the more interesting, and the Slashdot disagree mail senders are usually quite far indeed.
Of course there are people just making light of it as well, but even laughing is not necessarily a sign of not taking it seriously; it is a common reaction to something that is so far removed from one's normal reality that it is hard to digest.
Not that you don't have a point, but I cannot say that I agree completely. The thing is that computer software nowadays is supposed to be possible to use even without any prior education about it, which is a notion that I find quite ridiculous. To make another car analogy on Slashdot, I don't think anyone would expect a car to be driven by anyone with no prior experience of it whatsoever. In the end, it's no wonder that many users don't know what they're doing or doing things awfully wrong.
I would also be pleased to blame the WIMP-style GUI for these expectations. For some reason, it seems to inspire confidence in programmers, UI designers and end users alike that as long as the program uses a WIMP GUI, it is automatically usable with merely the end-user's intuition. In all fairness, a command-line interface at least does not bring those expectations with it, so that users aren't expected to be able to use such programs without any clue about what they're doing.
The details are these: Every node in the DNS tree has a key pair. Everybody knows the public key of the root.
That runs against my understanding, though. I can't call myself an expert on DNSSEC, but as I've understood it, a client can have a trust anchor at any node in the tree. Thus, the client can have the public key of the.gov TLD pre-installed and check its replies against it.
In fact, I think it seems haphazard to do otherwise. If the clients only knew and trusted the public key of the root server, then it would both require everyone to trust the root server operators (not that I don't, but I wouldn't want to have to), and it would create a single point of failure. If anyone h4xx3d the root zone's public key, they could fake the entire DNS.
I shan't call myself too knowledgeable about DNSSEC, but as far as I've understood it, it should be perfectly secure as long as the client systems have the.gov TLD's public key installed as an anchor of trust. Which they currently don't, of course, but that's another issue.
I don't see how they can do that. If the source is open, how could it possibly even be hard to remove that limit?
That being said, though, I would guess that the greatest contribution isn't actually the program itself, but rather the fact that it lays open the protocols involved, so that other MAPI servers could be written. Maybe it could even be implemented as another protocol for Dovecot?
His point was not that standardized APIs would disappear, but rather than graphics APIs, more specifically, would. He meant that it would be replaced by, simply, an API to load compiled code (shader code, that is) into the GPU and letting it run. The actual code could be freely written by the developer, and would not even necessarily be constrained to doing graphics processing.
Hold your finger on that trigger. Of course I realize that I'd be in trouble if the Linux community dissipated one day, but that's not what I'm arguing about. The millions of geeks and other technical users that Linux has had for many years now is more than enough to ensure that it doesn't become deprecated.
If Linux had 90% desktop share, right now today, Linux software would be in much better shape than it is...
Better shape in what way? Better GUI? In that case, I really could not care less, since I never use those fancy GUI programs anyway. And I really don't see any other major advantages that would be brought by having 90% desktop share.
...and there would be many many more programs for Linux. You like programs, don't you? That's what I thought.
No, I don't particularly like programs in themselves. I might, if I need them, like good programs, and mind you, at least 99% of all programs for Windows do not fit into those categories. They are either no good, being written in Visual Basic by the me of 10 years ago, or I don't need them, since they superfluously solve problems that could be solved with 5-10 lines of shell. Or, disturbingly often, both.
In fact, I'd say it is easier to find good and useful programs for Linux right now, than it is for Windows. If having 90% of the desktop market share will make people write the same kind of programs for Linux that are currently available for Windows, I'll have to decline the offer, thank you very much.
In many ways, I agree with you. I have no real drive to see people use the same system that I do. If they want to use Windows or some other non-free system, that's their problem.
However, I do have a very real drive to put the Microsoft monoculture out of action, since that would make for a much more interoperable world. I am actively troubled by people trying to send me MS Office files and people writing IE-only web pages. And getting people to use Linux is probably the best way to achieve the goal of avoiding that.
Mac OS X would work, too, though, so I try to evangelize Apple as well. However, if I'm getting people to switch, I would rather see them using a free system, and I don't think that the BSDs or Plan9 would be a good choice for very many end users. (Though to be sure, that goes for most Linux distros as well. If I evangelize anything, I'm trying to make it Ubuntu.)
What a weird question to ask. WebKit is a just a library for HTML rendering. It's like asking why Windows games don't run on Linux; after all, they're written in C, known to be a cross-platform language.
Chrome naturally consists of many other components as well, such as the actual user interface, all the glue code to actually read and write files (like the cache), doing network connections, DNS lookups, checking SSL certificates, handling its famous sandbox processes, loading plugins and all sorts of other things.
Not to mention, it should be quite similar to 24 hours of EMACS usage. The only question while programming might be how much battery juice the compiler saps.
Slashdot Mirror
Well, no, not really. Google cannot disable a program at all. All they can do is disable a distribution channel for it. In my mind, that's quite an important difference.
The difference is important because it does not affect Android as a platform at all. It only affects Google's app store. I can understand someone refusing to use Google's app store over this issue, but not anyone refusing to use Android.
(In fact, though, that last sentence shouldn't be said unrestricted. If it happens such that Android has some built-in, mandatory DRM scheme that is used for this kill-switch, that may be reason enough to hate Android.)
It may sound remote, but you may want to try RTFA:ing. I know it's not going to happen, though, so I'll summarize why it's OK for Google. :)
The thing is that Android allows for installing programs from -- hear and be astonished! -- other sources than Google itself, unlike Apple. Without any extra or undue inconvenience.
And, Android's kill switch is only for the programs that come through Google's own app store. So, you can probably pretty much bet that it's only going to be used to regulate malware, or Google's app store won't last long. Or if Google does misuse it, you'll just have to download the program in question directly from its developer.
It may sound remote, but you may want to try RTFA:ing. I know it's not going to happen, though, so I'll summarize why it's OK for Google. :)
The thing is that Android allows for installing programs from -- hear and be astonished! -- other sources than Google itself, unlike Apple. Without any extra or undue inconvenience.
And, Android's kill switch is only for the programs that come through Google's own app store. So, you can probably pretty much bet that it's only going to be used to regulate malware, or Google's app store won't last long. Or if Google does misuse it, you'll just have to download the program in question directly from its developer.
I could not agree more, and none to my surprise, TFA was full of inflated fluff and very little substance. It was hard enough to wade through it even to find anything substantial at all, but let me highlight some of the things that can be found:
In fact, many developers would rather be freed from the hassles imposed by traditional systems programming languages. VM-based languages offer such features as automatic garbage collection, runtime bytecode verification, and security sandboxes -- all of which translate into peace of mind.
Of course garbage collection has been a feature of LISP since its inception, which has been compilable to machine code since... the 60s? Not to mention the garbage collection libraries available for C and other languages. I'd care to call that point bogus.
Likewise, runtime bytecode verification isn't necessary with a hardware CPU. It's just made to ensure that a JVM doesn't encounter any illegal instructions or jump to code outside the current protection domain. Hardware CPUs can do illegal instruction checking in parellel with execution without penalties, and virtual memory makes the jump checks pointless as well. Not to mention that it is less restricted, so that one can implement such things as tail-call optimization or continuations without reimplementing the CPU.
Oh, and of course, operating systems have had security sandboxes called "processes" since... the 60s? Of course, one could well argue that it would be swell to be able to further control a process' privileges to a degree not available on, say, Linux or NT, but that isn't exactly something that requires a VM.
Dynamic languages, on the other hand, mean efficient coding; their high-level syntax makes it easy to conceptualize applications and build prototypes rapidly.
Yeah. But as Lisp, Psycho and countless others have demonstrated, they don't need a VM to run efficiently.
The great advantage of a generic VM, as opposed to a language-specific one, is flexibility.
Of course, exactly what a "generic" VM entails does not seem to be entirely clear to the author. Or at least, I can't find anything about it in TFA.
Oh, I take that back. My bad. I read that "Mozilla Firefox", rather that "Mobile Firefox", as it actually said. It might still be arguable that "Mobile Gecko" would be a lot more accurate, though.
Indeed, that's exactly what the summary said. They made it "available for the desktop", "to get Fennec in front of as many people as possible".
That's some typo in the headline. Or at least, I'm assuming that it's supposed to be "Fennec", and not "Firefox". I'm a bit impressed that that got through.
Look, I can beat you in an uptime contest.
Oh, but you couldn't beat him in a hipness contest, you vile non-Mac user. ;)
To get back on track, though, the parent's point wasn't really to never have to turn the notebook off, but merely that such features as sleep-to-RAM and hibernation pretty much negates the usefulness of an "instant on" system like the one in TFA.
It's one thing to have to reboot every once in a blue moon due to a kernel update (though I might suggest that you look into Debian stable if you are disturbed by frequency of updates ;) or hardware upgrades, but I'd be able to bet a lot that's not really the kind of opportunity that one would use an "instant on" system anyways. When you run into a low battery or even when switching OSes, you can just hibernate.
If anything, I for one would appreciate a coreboot-compatible notebook computer, since the BIOS seems to be what takes the longest time to get through when going back from hibernation. But that would most likely apply to the "instant on" system as well.
NT 3.something: Initial NT release with the version number written to match the non-NT Windows 3.x releases.
NT 4.x: The various versions of NT4.
NT 5.0: Windows 2000
NT 5.1: Windows XP
NT 5.2: Windows Server 2003
NT 6.0: Windows Vista
NT 6.1: Windows Server 2008
If I'm not terribly mistaken somewhere along those lines, it would seem to make sense if the next release of Windows (that is, Windows 7) would use kernel version 7.0.
I'd like to see some citation for the fact that Windows 7 would use NT 6.1. It might make sense if that shows in current test builds or leaked screen shots or something, since they probably just haven't increased the version number internally yet.
Although, like someone else pointed out, it doesn't seem like a good idea to rely on WPA alone to protect sensitive information anyway. If one really wants the information to be left alone, it should have been encrypted end-to-end using TLS from the start.
Then again, CA-signed certificates also suck. I've already written about it here, so I won't reformulate the problem in this post, but I'll quote the most relevant part:
---
The problem, then, is that this implies that you need to trust Verisign and Thawte to properly validate all the certificate requests that they get—people in an extremely large, bureaucratically weighed-down enterprise that process thousands of certificates daily using automated processes. What are the chances that they wouldn't let one single mistake slip through, and issue a certificate to a cracker for a site that he does not own? The problem does not end there, however: The certificates pre-installed on new PCs are not limited to Verisign and Thawte. They commonly ship with the certificates of around 50 different certificates organizations. Even if you feel secure in trusting Verisign and Thawte (which you should not, but more on that later), what are the chances that all of these can be trusted to consist entirely of incorruptible people and flawless processes? And, even if they did, what are the chances that all of them are completely secure and cannot themselves be cracked to produce faux certificates? For this reason alone, I, for one, would consider the entire process flawed and untrustworthy, and I would implore you to do the same. Therefore, Haven and Hearth uses its own, self-signed SSL certificate, bypassing the certificate authorities. To further clarify our stance, the following three points of policy are noteworthy:
But hold on, there is more to this. You may have read the preceding paragraph and still thought it all right to trust all these diverse organizations. However, you really should not: it is well documented that Verisign actively produces faux certificates for various purposes, especially for law enforcement agencies, so that they can perform MITM attacks. You can see Verisign's own home page if you doubt it. What Verisign's faux certificates mean in practice, is that their holder can impersonate any web site, to listen to the traffic between them and their visitors, modify their content arbitrarily and catch any and all sensitive information. And by that, I really mean any web site, not only those with certificates signed by Verisign in the first place. See, when the browser performs its certificate authenticity check, it checks the web site's certificate against any of its installed certificate authorities, and it does not even warn you if the web site's certificate has changed since the last time you visited it, as long as it is signed by just one of the certificate authorities it knows of. Of course, it is not only Verisign which is bestowed with this power – any of the certificate authorities can do th
The original reported problem of Windows only reporting 3 GB of RAM is probably related to one of the many problems described in this Microsoft article: http://www.microsoft.com/whdc/system/platform/server/PAE/PAEdrv.mspx
It doesn't mention Vista specifically, but it does list different physical address space limitation for the various editions of other Windows versions. Among others, XP is mentioned as being limited to 4 GB of physical address space, and I'd guess the cause of that would be its not being licensed for more than that. By similar reasoning, it wouldn't surprise me if most editions of Vista have the same limitation. I guess that's what you get for using evilware.
Honestly, why does the 2x RAM guideline make any sense?
It doesn't, and I'm surprised and chocked to see that noone here on Slashdot has posted the reason yet.
The reason why twice as much swap as RAM is commonly recommended is because an ancient Linux swap implementation (I don't know exactly when) was optimized that way. When there was twice as much swap as RAM, it performed the best. It has not been that way for years, though, so that recommendation is simply obsolete.
When you create your swap space today, you should simply be considering how much total virtual memory you want. Nothing more and nothing less.
Studying other people, their opinions, reactions and language is a basic part of human behavior, wouldn't you agree? The further from oneself the objects of the study are, the more interesting, and the Slashdot disagree mail senders are usually quite far indeed.
Of course there are people just making light of it as well, but even laughing is not necessarily a sign of not taking it seriously; it is a common reaction to something that is so far removed from one's normal reality that it is hard to digest.
I would also be pleased to blame the WIMP-style GUI for these expectations. For some reason, it seems to inspire confidence in programmers, UI designers and end users alike that as long as the program uses a WIMP GUI, it is automatically usable with merely the end-user's intuition. In all fairness, a command-line interface at least does not bring those expectations with it, so that users aren't expected to be able to use such programs without any clue about what they're doing.
Evince has been doing that for quite a while now, thank you.
The details are these: Every node in the DNS tree has a key pair. Everybody knows the public key of the root.
That runs against my understanding, though. I can't call myself an expert on DNSSEC, but as I've understood it, a client can have a trust anchor at any node in the tree. Thus, the client can have the public key of the .gov TLD pre-installed and check its replies against it.
In fact, I think it seems haphazard to do otherwise. If the clients only knew and trusted the public key of the root server, then it would both require everyone to trust the root server operators (not that I don't, but I wouldn't want to have to), and it would create a single point of failure. If anyone h4xx3d the root zone's public key, they could fake the entire DNS.
I shan't call myself too knowledgeable about DNSSEC, but as far as I've understood it, it should be perfectly secure as long as the client systems have the .gov TLD's public key installed as an anchor of trust. Which they currently don't, of course, but that's another issue.
That being said, though, I would guess that the greatest contribution isn't actually the program itself, but rather the fact that it lays open the protocols involved, so that other MAPI servers could be written. Maybe it could even be implemented as another protocol for Dovecot?
His point was not that standardized APIs would disappear, but rather than graphics APIs, more specifically, would. He meant that it would be replaced by, simply, an API to load compiled code (shader code, that is) into the GPU and letting it run. The actual code could be freely written by the developer, and would not even necessarily be constrained to doing graphics processing.
If Linux had 90% desktop share, right now today, Linux software would be in much better shape than it is...
Better shape in what way? Better GUI? In that case, I really could not care less, since I never use those fancy GUI programs anyway. And I really don't see any other major advantages that would be brought by having 90% desktop share.
...and there would be many many more programs for Linux. You like programs, don't you? That's what I thought.
No, I don't particularly like programs in themselves. I might, if I need them, like good programs, and mind you, at least 99% of all programs for Windows do not fit into those categories. They are either no good, being written in Visual Basic by the me of 10 years ago, or I don't need them, since they superfluously solve problems that could be solved with 5-10 lines of shell. Or, disturbingly often, both.
In fact, I'd say it is easier to find good and useful programs for Linux right now, than it is for Windows. If having 90% of the desktop market share will make people write the same kind of programs for Linux that are currently available for Windows, I'll have to decline the offer, thank you very much.
However, I do have a very real drive to put the Microsoft monoculture out of action, since that would make for a much more interoperable world. I am actively troubled by people trying to send me MS Office files and people writing IE-only web pages. And getting people to use Linux is probably the best way to achieve the goal of avoiding that.
Mac OS X would work, too, though, so I try to evangelize Apple as well. However, if I'm getting people to switch, I would rather see them using a free system, and I don't think that the BSDs or Plan9 would be a good choice for very many end users. (Though to be sure, that goes for most Linux distros as well. If I evangelize anything, I'm trying to make it Ubuntu.)
Well, I do let logrotate throw away old logs a lot faster than 18 months, though.
Chrome naturally consists of many other components as well, such as the actual user interface, all the glue code to actually read and write files (like the cache), doing network connections, DNS lookups, checking SSL certificates, handling its famous sandbox processes, loading plugins and all sorts of other things.
Not to mention, it should be quite similar to 24 hours of EMACS usage. The only question while programming might be how much battery juice the compiler saps.