C'mon, you think I execute shell commands by writing a C program that calls fork(), exec(), and pipe()?
In other words, you acknowledge that there's at least some truth to what you were arguing against -- that machines are fast enough that for at least some purposes (I'd argue many), CPU time is cheaper than developer time.
The people who still won't acknowledge that there is a real reason C and C++ are still the languages of OS kernels.
That reason is mostly historical significance.
No, I'm not suggesting Java, specifically. But really, we can do better, even for a traditional kernel. C and C++ are not the only compiled languages worth considering.
It's not premature optimization to write libavcodec in C.
Has it been tried in other languages? And would it be premature to write it in assembly? (I'll bet some parts of it are in assembly, on supported architectures.)
In particular, if I see another order-of-magnitude increase in computing power without a comparable increase in codec complexity, I'd much rather have a libavcodec that doesn't crash, even if it's 2-3x slower.
I've really appreciated just being able to pull down a single executable from a site and have it "just work".
Have you ever done that? Even once?
I'm willing to bet you haven't -- that you've instead downloaded zips, dmgs, or mpkgs, neither of which are executables, and all of which would be perfectly capable of including multiple binaries and a script to select the correct one.
my tolerance for pointless frustration decreases steadily with age.
That's why I use a package manager, which eliminates the whole issue -- I just need the name of a package, and it Just Works.
Obviously if there weren't clear benefits, there wouldn't be such broad support for this concept.
Appeal to popularity -- a bit of a fallacy. For example, there's broad support for religion, but I am not religious. There's also broad support for Windows, but I use Linux.
With multi-architecture binaries and libraries, you can test and debug the 32-bit and 64-bit versions of an application without rebooting into a separate OS, without building some weird chroot environment,
Neither of which is required currently.
Special linker, if it's there, is already done.
Another big advantage is that if you build a universal install DVD, you have half as many binary packages.
Wrong -- you have half as many binary files. The number of packages can remain the same.
Can you come up with a single example which isn't handled trivially by a script which selects the appropriate binary?
Except that in the case of OS X, there's already the existing formats everyone uses (zip/dmg/mpkg) which all support this. I really have no idea why they chose to go with building it into the binary itself.
Chrome (Chromium) is open source. I'm running the nightly on Linux.
This means that if Google ever drops the ball on support, the community can fill in. I can't imagine it'll fall behind once the initial port is done, if any Linux users at all are interested in maintaining it.
sure, maybe Java/garbage-collection/50mb-binaries/etc. are a little slower,
Let's see...
chromium-browser is a 38 meg binary on my system, and that's just the binary. The libraries it distributes bump it up above 40 megs, and it's probably easily 45 or 50 with all the system libraries it pulls in.
Here's an example of where you're both very right, and very wrong:
You're very right in that speed still matters, and always will. By applying a little optimization at just the right point, we gain massive speed boosts for everyone. For example, Webkit instead of Gecko, and all the little tweaks of v8, make Chrome's HTML, Javascript, and CSS at least on par with, and usually several times better than the competition.
On the other hand, you're entirely wrong about the argument you've used. Tons of stuff in Chrome, including the entire extension API, is done entirely in HTML and Javascript, because they are fast enough. I'll give you a stupidly simple example: Hit "new tab". That entire New Tab page is HTML and Javascript.
Want proof? Ctrl+U.
Want more? Next time you start a download, open the download list/manager. HTML and Javascript. In fact, the only things that aren't HTML and Javascript are the Chrome itself -- the toolbar, tab bar, and status bar. Even the toolstrip bar, managed by extensions, is mostly HTML and Javascript.
At a lower level, much of the core Javascript library in Chrome is, in fact, written in Javascript.
Guess what? Javascript is a little slower than C++. It's also garbage-collected.
Guess what else? Even if you could theoretically do these pages in C++, programmer productivity is still more important.
What did we learn?
Premature optimization is the root of all evil. Chrome is fast not because speed always matters, but because speed matters at the specific points they targeted.
If you know anything about Javascript, you know how difficult it must have been for the v8 team -- yet if you look at the v8 presentation, much of the optimization they do is remarkably obvious in hindsight. So the second thing we learned is that Java is not slow. A language is generally not fast or slow, by its very nature -- while some aspects of language design can make it easier or harder to optimize a language, it is ultimately the implementation that is fast or slow.
Conventional wisdom (like what you're spouting) says Javascript is slow. Chrome proves otherwise. Remember that the next time anyone says something as stupid as "Ruby is slow."
it will never be faster, more reliable, or safer than simply not running any JavaScript at all.
Unless "not running any JavaScript at all" requires using a less secure browser.
Blocking all JavaScript by default, with the ability to individually white-list individual items (close, but not quite, Opera), is a bare minimum requirement for safe web surfing.
No, it's an extreme. It's a "bare minimum" like the thumb reader on my laptop is a "bare minimum" -- buys me almost no real security, makes things more cumbersome to use, and the time and effort would be better spent elsewhere.
One example: Chrome's sandboxing makes the entire browser more secure against any web compromise, whether it originates from script, HTML, CSS, images, anything. It's not there yet, but you can imagine it dialed up to where individual iframes have their own render process, to where Flash in one tab physically can't touch Flash in another tab. It's not a new idea, Postfix has been doing it for years (decades?), but if anything needs this, browsers do.
Blocking advertisements does more to speed up real-world browsing speed (not just benchmarks) than any other single change.
Yes and no.
Yes, and that's the reason I wrote an adblocker extension for Chrome. It took about an afternoon, including learning the Chrome extension API. I once spent an afternoon just trying to play with writing a Firefox addon...
But no, sorry, sometimes you actually do benefit directly from the browser being fast. I'm willing to bet that Slashdot with ads enabled is still more pleasant to use with the new AJAX in Chrome, than it is with ads disabled and no JavaScript in any other browser.
If either Opera or Chrome would implement those two feature sets
Worth mentioning that you can implement them for all browsers with privoxy.
The first difference you mentioned is C/C++ code vs JavaScript. FWIW, Chrome does actually cache compiled javascript somewhere.
And no, I don't agree with this:
they aren't shooting for the same targets. Chrome is trying to be as fast as possible so Google's webapps run fast and feel more like native apps. FireFox on the other hand is trying to be far more flexible.
Except Chrome's extension API, while incomplete and not as powerful, is much cleaner and simpler to use -- it's just HTML and Javascript. But then, it's also been rumored that Chrome intends to support Firefox extensions, eventually.
In other words: You can have the best of both worlds. But it's hard to do that from Firefox's codebase. It's a lot easier to start with Chrome and write an extension.
Here's the thing: Clicking something and having the action take place instantly makes that unnecessary for quite a lot of tasks. And that goes not just for links to new pages (though that is a factor), but for links that drive Javascript.
I'll give you an example: I always hear people whining about the new Slashdot AJAX crap. I agree, it's bloated and completely unnecessary, and on Firefox and Konqueror, it's slow as hell. In Chrome, it's actually faster than the old system -- click reply, half a second later there's a reply box ready to type, and that's about the longest anything takes here. Clicking on a semi-hidden thread to expand it is even faster.
Granted, that's not "instantly", the way so much of the Web has become for me. But the difference is pretty staggering, and pretty significant.
I still use tabs almost the way you do, but that's when I have a slow connection, or a bunch of links that I can't easily visit in serial.
Well, except that since this is the government, you're going to have to deal with whoever's elected. So a vote for a lesser evil is still a vote against a greater evil.
I'm pretty sure those aren't actually monthly, and I'm also pretty sure that Linux has similar problems.
Now, Linux has a much better track record of security and stability, and that's not entirely due to it being unpopular. But the long-term solution to malware is not technological, because any machine that's hackable in the good sense -- that is, powerful enough for the user to do whatever they want, to use it as a general purpose machine -- is also crackable by social engineering, which is how most malware works these days.
Lest you accuse me of being a corporate shill: I'm typing this on Kubuntu 9.04, from a Chromium nightly.
They also deserve to have more opportunities to learn critical thinking, and see it reinforced. But it's a bit like anyone going off chemotherapy and onto homeopathy -- you deserve what you get.
(To anyone about to defend homeopathy: IT'S WATER.)
If you're going that route, I liked tomsrtbt. Most floppies and drives support the higher density, and it had everything I needed, back when I used floppies at all.
Unless your hardware is old enough that the kernel taking some 3-4 megs (instead of fitting on a floppy disk) is an issue, newer software is probably better.
Just go lightweight.
I would say Debian or Arch, not Gentoo. I like Fluxbox as a window manager, for a light system. That's about it -- add other things as needed.
I mean a license where I could look at the source and not have to sign away other rights.
For example: One kind of intolerable license is what the Flash specs used to be available under, which forbade anyone from reading them to develop a player. In other words, if I didn't read the Flash specs, I'd be allowed to work on Gnash, but if I did read the specs, I could only develop authoring and server-side tools.
I believe Adobe has fixed this recently, but you can see why I have a problem with that kind of license, more so than with a license which simply says "Noncommercial only," or "Must be under the same license," or even "You can't redistribute this," (or better, "You can't distribute any modified copies,") all of which would tend to prevent others from using it in their own products.
OpenOffice does seem to have better compatibility -- though, oddly, AbiWord seems to create much cleaner, more human-readable ODT files than OpenOffice.
The main advantage is that AbiWord was much lighter, partly because it's just a word processor. I used to use AbiWord for word processing, Gnumeric for spreadsheets, etc. Which doesn't matter to me anymore, now that OpenOffice starts in about two seconds for me, cold or hot.
The main other advantage of OpenOffice was stability -- AbiWord used to crash a lot, but that seems to have gotten better.
Slashdot Mirror
C'mon, you think I execute shell commands by writing a C program that calls fork(), exec(), and pipe()?
In other words, you acknowledge that there's at least some truth to what you were arguing against -- that machines are fast enough that for at least some purposes (I'd argue many), CPU time is cheaper than developer time.
The people who still won't acknowledge that there is a real reason C and C++ are still the languages of OS kernels.
That reason is mostly historical significance.
No, I'm not suggesting Java, specifically. But really, we can do better, even for a traditional kernel. C and C++ are not the only compiled languages worth considering.
It's not premature optimization to write libavcodec in C.
Has it been tried in other languages? And would it be premature to write it in assembly? (I'll bet some parts of it are in assembly, on supported architectures.)
In particular, if I see another order-of-magnitude increase in computing power without a comparable increase in codec complexity, I'd much rather have a libavcodec that doesn't crash, even if it's 2-3x slower.
I've really appreciated just being able to pull down a single executable from a site and have it "just work".
Have you ever done that? Even once?
I'm willing to bet you haven't -- that you've instead downloaded zips, dmgs, or mpkgs, neither of which are executables, and all of which would be perfectly capable of including multiple binaries and a script to select the correct one.
my tolerance for pointless frustration decreases steadily with age.
That's why I use a package manager, which eliminates the whole issue -- I just need the name of a package, and it Just Works.
Obviously if there weren't clear benefits, there wouldn't be such broad support for this concept.
Appeal to popularity -- a bit of a fallacy. For example, there's broad support for religion, but I am not religious. There's also broad support for Windows, but I use Linux.
With multi-architecture binaries and libraries, you can test and debug the 32-bit and 64-bit versions of an application without rebooting into a separate OS, without building some weird chroot environment,
Neither of which is required currently.
Special linker, if it's there, is already done.
Another big advantage is that if you build a universal install DVD, you have half as many binary packages.
Wrong -- you have half as many binary files. The number of packages can remain the same.
Can you come up with a single example which isn't handled trivially by a script which selects the appropriate binary?
Except that in the case of OS X, there's already the existing formats everyone uses (zip/dmg/mpkg) which all support this. I really have no idea why they chose to go with building it into the binary itself.
You're confusing a single vulnerability with a systemic problem. When this is fixed, that's what SSL certificate providers will do again.
Indeed, I do see the countdown here in Chromium on Linux.
Chrome (Chromium) is open source. I'm running the nightly on Linux.
This means that if Google ever drops the ball on support, the community can fill in. I can't imagine it'll fall behind once the initial port is done, if any Linux users at all are interested in maintaining it.
Actually, you're proving those people's point:
sure, maybe Java/garbage-collection/50mb-binaries/etc. are a little slower,
Let's see...
chromium-browser is a 38 meg binary on my system, and that's just the binary. The libraries it distributes bump it up above 40 megs, and it's probably easily 45 or 50 with all the system libraries it pulls in.
Here's an example of where you're both very right, and very wrong:
You're very right in that speed still matters, and always will. By applying a little optimization at just the right point, we gain massive speed boosts for everyone. For example, Webkit instead of Gecko, and all the little tweaks of v8, make Chrome's HTML, Javascript, and CSS at least on par with, and usually several times better than the competition.
On the other hand, you're entirely wrong about the argument you've used. Tons of stuff in Chrome, including the entire extension API, is done entirely in HTML and Javascript, because they are fast enough. I'll give you a stupidly simple example: Hit "new tab". That entire New Tab page is HTML and Javascript.
Want proof? Ctrl+U.
Want more? Next time you start a download, open the download list/manager. HTML and Javascript. In fact, the only things that aren't HTML and Javascript are the Chrome itself -- the toolbar, tab bar, and status bar. Even the toolstrip bar, managed by extensions, is mostly HTML and Javascript.
At a lower level, much of the core Javascript library in Chrome is, in fact, written in Javascript.
Guess what? Javascript is a little slower than C++. It's also garbage-collected.
Guess what else? Even if you could theoretically do these pages in C++, programmer productivity is still more important.
What did we learn?
Premature optimization is the root of all evil. Chrome is fast not because speed always matters, but because speed matters at the specific points they targeted.
If you know anything about Javascript, you know how difficult it must have been for the v8 team -- yet if you look at the v8 presentation, much of the optimization they do is remarkably obvious in hindsight. So the second thing we learned is that Java is not slow. A language is generally not fast or slow, by its very nature -- while some aspects of language design can make it easier or harder to optimize a language, it is ultimately the implementation that is fast or slow.
Conventional wisdom (like what you're spouting) says Javascript is slow. Chrome proves otherwise. Remember that the next time anyone says something as stupid as "Ruby is slow."
Nope. Chrome supports ActiveX.
The only holdout IE can claim is corporate intranets and other hideously nonstandard websites.
it will never be faster, more reliable, or safer than simply not running any JavaScript at all.
Unless "not running any JavaScript at all" requires using a less secure browser.
Blocking all JavaScript by default, with the ability to individually white-list individual items (close, but not quite, Opera), is a bare minimum requirement for safe web surfing.
No, it's an extreme. It's a "bare minimum" like the thumb reader on my laptop is a "bare minimum" -- buys me almost no real security, makes things more cumbersome to use, and the time and effort would be better spent elsewhere.
One example: Chrome's sandboxing makes the entire browser more secure against any web compromise, whether it originates from script, HTML, CSS, images, anything. It's not there yet, but you can imagine it dialed up to where individual iframes have their own render process, to where Flash in one tab physically can't touch Flash in another tab. It's not a new idea, Postfix has been doing it for years (decades?), but if anything needs this, browsers do.
Blocking advertisements does more to speed up real-world browsing speed (not just benchmarks) than any other single change.
Yes and no.
Yes, and that's the reason I wrote an adblocker extension for Chrome. It took about an afternoon, including learning the Chrome extension API. I once spent an afternoon just trying to play with writing a Firefox addon...
But no, sorry, sometimes you actually do benefit directly from the browser being fast. I'm willing to bet that Slashdot with ads enabled is still more pleasant to use with the new AJAX in Chrome, than it is with ads disabled and no JavaScript in any other browser.
If either Opera or Chrome would implement those two feature sets
Worth mentioning that you can implement them for all browsers with privoxy.
So let's see...
The AC has already mentioned some userscripts. I've written one that uses CouchDB and works as a native Chrome extension.
And you probably want to look for the SmoothScroll extension. It doesn't work for all webpages, but when it works, it works.
The first difference you mentioned is C/C++ code vs JavaScript. FWIW, Chrome does actually cache compiled javascript somewhere.
And no, I don't agree with this:
they aren't shooting for the same targets. Chrome is trying to be as fast as possible so Google's webapps run fast and feel more like native apps. FireFox on the other hand is trying to be far more flexible.
Except Chrome's extension API, while incomplete and not as powerful, is much cleaner and simpler to use -- it's just HTML and Javascript. But then, it's also been rumored that Chrome intends to support Firefox extensions, eventually.
In other words: You can have the best of both worlds. But it's hard to do that from Firefox's codebase. It's a lot easier to start with Chrome and write an extension.
I used to be like you. Still am, in a way.
Here's the thing: Clicking something and having the action take place instantly makes that unnecessary for quite a lot of tasks. And that goes not just for links to new pages (though that is a factor), but for links that drive Javascript.
I'll give you an example: I always hear people whining about the new Slashdot AJAX crap. I agree, it's bloated and completely unnecessary, and on Firefox and Konqueror, it's slow as hell. In Chrome, it's actually faster than the old system -- click reply, half a second later there's a reply box ready to type, and that's about the longest anything takes here. Clicking on a semi-hidden thread to expand it is even faster.
Granted, that's not "instantly", the way so much of the Web has become for me. But the difference is pretty staggering, and pretty significant.
I still use tabs almost the way you do, but that's when I have a slow connection, or a bunch of links that I can't easily visit in serial.
Well, except that since this is the government, you're going to have to deal with whoever's elected. So a vote for a lesser evil is still a vote against a greater evil.
Can I stop supporting IE6 now? Just throw up a "please upgrade" link?
I'm pretty sure those aren't actually monthly, and I'm also pretty sure that Linux has similar problems.
Now, Linux has a much better track record of security and stability, and that's not entirely due to it being unpopular. But the long-term solution to malware is not technological, because any machine that's hackable in the good sense -- that is, powerful enough for the user to do whatever they want, to use it as a general purpose machine -- is also crackable by social engineering, which is how most malware works these days.
Lest you accuse me of being a corporate shill: I'm typing this on Kubuntu 9.04, from a Chromium nightly.
they've forgotten critical thinking.
And as such, I say they deserve what they get.
They also deserve to have more opportunities to learn critical thinking, and see it reinforced. But it's a bit like anyone going off chemotherapy and onto homeopathy -- you deserve what you get.
(To anyone about to defend homeopathy: IT'S WATER.)
Is there a reason "print to PDF" isn't sufficient, for anything you'd use a Word document for?
The U.S. has the freest internet access in the WHOLE WOILD!
If true, that's pretty sad.
Fortunately, I'm pretty sure it's not true.
If you're going that route, I liked tomsrtbt. Most floppies and drives support the higher density, and it had everything I needed, back when I used floppies at all.
Unless your hardware is old enough that the kernel taking some 3-4 megs (instead of fitting on a floppy disk) is an issue, newer software is probably better.
Just go lightweight.
I would say Debian or Arch, not Gentoo. I like Fluxbox as a window manager, for a light system. That's about it -- add other things as needed.
I mean a license where I could look at the source and not have to sign away other rights.
For example: One kind of intolerable license is what the Flash specs used to be available under, which forbade anyone from reading them to develop a player. In other words, if I didn't read the Flash specs, I'd be allowed to work on Gnash, but if I did read the specs, I could only develop authoring and server-side tools.
I believe Adobe has fixed this recently, but you can see why I have a problem with that kind of license, more so than with a license which simply says "Noncommercial only," or "Must be under the same license," or even "You can't redistribute this," (or better, "You can't distribute any modified copies,") all of which would tend to prevent others from using it in their own products.
That's what I meant by "actually all of it."
Right. Hell is a bit chilly, but hasn't frozen over until the source is actually released, and it's actually all of it, and under a tolerable license.
OpenOffice does seem to have better compatibility -- though, oddly, AbiWord seems to create much cleaner, more human-readable ODT files than OpenOffice.
The main advantage is that AbiWord was much lighter, partly because it's just a word processor. I used to use AbiWord for word processing, Gnumeric for spreadsheets, etc. Which doesn't matter to me anymore, now that OpenOffice starts in about two seconds for me, cold or hot.
The main other advantage of OpenOffice was stability -- AbiWord used to crash a lot, but that seems to have gotten better.