You need to actually watch some of the reviews over the past few years, and current year that are done by photo professionals.
When I was doing research in 2003 (which is withing the "past few years") for a larger format photo printer, the Canon i9100 beat out the Epson 2200 for quality, according to the reviews I found. Both are 6 color photo printers, and the 2200 was the latest model, large format printer from Epson.
From what I've read, the print quality between the Epsons and the Canons is pretty close, no matter who's reviews you read. With the quality so close, what it came down to for me was the history of print head clogs on the Epsons and the Canon's faster speed.
I was being facetious. Sun has an established history of taking popular libraries, duplicating them, and embedding them in the standard library. This is a large part of why the Java API is so bloated these days.
In fact, every other brands' heads gum up so easily that they put disposable print heads on the print cartridge, where Epson printers come with permanent print heads.
Just FYI, the Canon i9100 comes with permanent print heads. You can order a replacement head from Canon and replace the carriage yourself, but the print heads aren't embedded in the ink cartridges. Epson heads can be replaced, too, but you have to send the entire printer in; it isn't a DIY job.
This is news because Canon and Epson each have their strengths.
Canon printers tend to be significantly faster then their same-generation Epson counterparts, and tend to do a little better with color reproduction. Epsons, on the other hand, are much better for longevity and certainly produce better black and white photographic prints.
I've got three printers at home now, and each serves a different function. I'll probably buy an Epson for B/W printing as soon as I can find a place to hide it so my wife doesn't see it. The silly woman thinks we have too many printers as it is.
No, I think the preferred way is to use real bindings, although I haven't done a speed test to see if there's any real advantage to a true binding. I like Ruby/DL because I've been able to write a cross-platform binding for Matlab with it -- something I was unsuccessful at doing with the standard method. As you suspect, not requiring a C compiler is a huge advantage, especially on Windows.
OCaml's major problem is that, like every other functional language available today, the breadth of its standard library and third-party libraries is totally pathetic in comparison to the likes of Java and Python. The same limitation applies to Lisp, Scheme, Haskell, Erlang, etc.
I don't know; I've always been able to find libraries that I needed for Haskell; there are quite a few listed on the Haskell libraries page. It seemed to me, when I was evaluating OCaml, that a lack of libraries bindings or bindings to other language's libraries was not a problem. They've got quite a decent database of extensions at The Camel Humps
I'm mainly a Java and Ruby developer, though, so I may not have stressed tested the availability of Haskell libraries. Java doesn't use libraries; if somebody writes a third-party library for it, Sun re-implements it, poorly, and bundles it with the VM, which effectively kills the original, and often superior, library. And Ruby... well, you just create whatever bindings you need, dynamically, with 'dl'.
I agree with most of what you said, but I don't understand this:
How GCC actually functions
On what do you base this claim? If you're talking about the GCC options in make.conf, that's entirely optional. I just use the default options -- I did choose the correct architecture as suggested by the comments, but this in no way imparts knowledge of how GCC "actually functions" -- I'm entirely clueless about GCC, and I get along well with Gentoo.
Recently, while adding a stall to a barn, I briefly toyed with the idea of doing a photo howto essay titled, "How to Add an Addition to Your Barn With A Dremel". Of course, you'd need just a couple of other, minor, "auxiliary" things, like wood, nails, a hammer, a reciprocating saw, a circular saw, a tape measure... but like most Dremel owners, my primary tool (even if it isn't used much) is the Dremel.
Anyway, the Dremel is great if all you want to do is scour a pattern into the skin of a pumpkin, but none of the bits (that I've been able to find) are long enough to actually cut a hole in an average pumpkin. On top of that, even at the lowest speed, you end up with pumpkin paste and orange mist.
At least, IME. The best tool I've found is indeed one of those cheapo pumpkin carving sets with dayglow handles and rigid, roughly serrated knives -- usually one thick, and one thin. We got one this year that came with a rigid spatula that worked really well, too.
Even so, I wish Dremel would come out with an extra-long, pumpkin-specific bit.
My concern is that we use wisdom in the race to build bigger and better weapons. Do we REALLY need a weapon like this?
No, we don't, but there is -- arguably -- a lot of benefit to be had from knowing how the technology works, if only to know what it is going to take for someone else to do it. Even if we don't research it, somebody will, and if we don't know how it works, we won't be able to train James Bond in disarming it.
Incidentally, this would be quite nice to have, from a military point of view. Sure, it is expensive, but theoretically, once you have the factory, all you need is some solar panels to produce the stuff. You have to mine Uranium, and fissionables are heavy. If you ignore the cost of getting the factory into orbit (which is a stupid thing to ignore), this is great. Create it right in orbit, drop it on your Axis of Evils, whoever they happen to be at the moment. Heck, assuming you can get the plant small enough, it'd be a real treasure -- it doesn't matter if it isn't making much antimatter, because it can be making it all the time, for free.
Anyway, knowing how to get around with this technology is useful, even if we (hopefully) never actually use it. Security through obscurity is false security.
There are a lot of caveats in my post; for instance, if you're strategically in orbit, there are all sorts of things you can drop on things that are way less expensive than antimatter. Personally, I think there's a reasonable chance that a good number of the 8,000 larger-than-softball objects in low orbit are ceramic balls with some depleted uranium, a tiny radio, simple microprocessor, and some navigational explosives. The only thing that keeps me from being totally paranoid about it is the Discordian truism: Govornments are the kinds of things which, although they do small things badly, do large things badly, too.
The last really good Palm was the Palm V. If I wanted to carry a brick around, I'd buy a Zaurus and get a real computer.
Palm has forgotten the mantra of the original developers that made the Palm III such a success -- keep it small. The Tungsten T is just barely carryable, and the newer versions just keep getting bigger. Personally, I'd rather see Palm spend their energy reducing the size of the T series than increasing the features.
Voting systems are one of those things people will ALWAYS disagree on
Except that everybody who is even a little educated about the matter agrees that first-past-the-post (the US system) is the worst possible voting mechanism, and that any of the proposed changes would be an improvement.
IE, even Approval Voting advocates would accept IRV or Borda if it was the only way to change the system, and vice versa.
Seriously. As they taught my dad in the military re people hopping fences into the SAC missile bases and he later taught me, "While you're shooting at his leg, he's shooting at your head. When you need to shoot at all, you shoot to kill. If you don't need to kill, you don't need to shoot."
Hm. I think you misunderstood your dad, or he misremembered his training. I'm sure they taught him to shoot to kill, but not because the enemy is "shooting at your head" while you're shooting at his leg. The real reason is because it's hard enough to hit somebody in a combat situation without trying to shoot hit something with as little surface area as a leg, or arm, or a head. You shoot at the torso, because it gives you the best chance of actually hitting them. And you don't shoot at someone's head, unless you're really close and they aren't moving.
There are exceptions, obviously. With plenty of training and skill, and some decent equipment, good conditions, and sufficient time for aiming, you can place your shots pretty well.
You vote for a third party. Really, people, it's not that hard.
That's how we ended up in this mess in the first place. A large number of people voted for third parties in 2000. We still ended up with a major party in charge, but we ended up with the greater of two evils. It is going to continue this way until we get an alternate voting system, like runoff or approval voting.
It is clear that most of the people who voted for Nader would have preferred Gore to Bush, and the Green party was the leading third party 2000. In voting for Nader, Green voters sabotaged the system (from their own point of views) and cost Gore the election, thus proving -- for those people -- that the American election system does not work. I'd go further and propose that many people who did vote for Gore or Bush would have preferred somebody else, but knew that a vote for a third party in the USA is a waste of a vote. Not only the Greens are disenfranchised by our existing system; Buchanan voters got their preferred second choice this time around, but only because they got lucky that there was massive voting fraud in Florida. Libertarians have been consistently disenfranchised for -- well, forever. The last time we had a third party president elected was in 1860, when Lincoln was elected.
Admittedly, I was part of the problem in 2000; I voted for a third party, too. I won't make that mistake this time around, though. I don't know if Kerry will make a bad president, but I know Bush is a bad one, and I'll take a chance on someone who hasn't proven himself to be incompetent.
In other news, just as their stock price was dipping to new lows, SCO dropped another entirely unexpected bombshell by claiming that they've discovered that IBM was actually founded by Darl McBride, and that the entire company (IBM) was in violation of the second law of thermodynamics.
On this news, SCO's stock jumped five points as more clueless, mostly stupid investors with learning disabilities threw more of their money away.
Now you know why a lot of people enjoy motorcycles.
Back in '88 I had a Nighthawk that I couldn't work on myself: the engine was mostly inaccessible without disassembling the entire bike, and the electronics were obtuse. On the other hand, I had a Ford LTD that I could take apart with just three tools.
Bikes are no easier to work on than cars; it just depends on which bike (or car) that you buy.
You would have loved NeXTSTEP. You could drag-and-drop from anything to anything. I think some automatic heuristics in the GUI toolkit itself really helps here, and I'm not surprised that MacOSX inherited this from NeXTSTEP.
If you need decent Unicode support, don't try Ruby, 'cos it's author arbitrarily dislikes Unicode and refuses to implement it.
The dislike isn't arbitrary. There is considerable resistance in Japan and China to Unicode, in part due to the fact that the ordering of characters is different than the order of established standards. The same is true for East Indian languages (although the objections are rather different).
Unicode is western-centric, a bias that can be seen in the fact that 7-bit ASCII maps one-to-one to UTF-8. Imagine, if you will, if -- rather than a clean 1-1 mapping of ASCII-7 to UTF-8 -- UTF-8 rearranged the characters, so they were ordered:
P e g 6 u l o G K x 1...
These aren't the only objections, but they illustrate that any dislike of Unicode is far from arbitrary.
Ruby does have Unicode support; granted, Ruby strings are not UTF-8 by default, like they are in Java, and you can't write Ruby programs using UTF-8 characters for variable names, and so on, like you can in Java. But Ruby does have basic support for dealing with UTF-8 strings, sufficient for most purposes.
Although its used in openoffice and jedit, no other java programs I use regularly spring to mind
Most of your Java usage, then, is probably invisible to you, being servlets running on websites that you visit.
My only real complaint about Java clients on Linux, at the moment, is the fact that they integrate so poorly. I can't drag-n-drop from KDE into Java apps. Java applications can't make use of things like KParts, and therefore re-implement a lot of wheels, which is tedious for both developers and users.
The VMs have come a long way in terms of speed on both the client and the server, but integration is a pretty major limitation for some people -- heck, I won't even use Gnome apps for the same reason. I'd rather use a shell, where I can at least pipe data between commands.
According to Tannenbaum, Minix -- being a microkernel -- has several advantages over a monolithic kernel. Speed isn't one of them, but he says that there are many cases where speed isn't the most important issue; for example, if you could get increased reliability, or an improved kernel development process, etc.
In any case, let's pretend he's right, for the sake of an argument, and that a microkernel is better than a monolithic kernel. In that case, here's what I predict: somebody in the Minix community will figure out how to leverage the existing Linux drivers and modules, and will produce Minux(tm)... a Linux with the kernel replaced by a Minix microkernel, using the vast number of existing Linux drivers and software. Since we already said that a microkernel is better than a monolithic kernel, this new Minux will rapidly surpass Linux in popularity.
Not. Because we all know that technical superiority doesn't guarantee success (betamax vs. VHS, Linux vs. Windows). However, it is an interesting possibility to think about.
Caveat: I am not a kernel hacker, and it has been a loooong time since my OS theory classes, so I have no idea how feasible something like this would be. I wish I did, because then I'd do it myself, and I'd become the next Linus Torvalds, and then I'd rule the world!!! Bwahahahahaha!!!!
Be sure when you're done with your laptop to put it out with a bucket of water
Ah, you must not have read the announcement. These things produce their own water. The next obvious step is to construct a tiny internal fire suppression system.
Actually, the sneaker benefit of this technology is that your laptop will steam-press your pants for your... or, at least, the thighs of your pant legs.
You imply above that let should always have let rec semantics
Actually, no... I imply that the compiler should be smart enough to see that a function recurses, and automatically flag it as such. I'm saying that the programmer is having to do work the compiler should be able to do.
Can a function be recursive without being defined as "let rec"? If so, then "let rec" is indeed purely a scoping mechanism, and although I still don't understand how the scoping rules affects the code, I can accept that it may be useful. However, if recursive functions, and only recursive functions, are defined as "let rec", then I propose that the compiler should be able to determine this from the code itself.
if you want floats, you have to write the expression differently.
What if I want a polymorphic function, that will accept either floats or integers? What if I have n methods that do some operations on numbers... how many methods do I have to write to support both ints and floats? Do I have to copy and paste the contents of the methods, even if they're practically identical?
Slashdot Mirror
When I was doing research in 2003 (which is withing the "past few years") for a larger format photo printer, the Canon i9100 beat out the Epson 2200 for quality, according to the reviews I found. Both are 6 color photo printers, and the 2200 was the latest model, large format printer from Epson.
From what I've read, the print quality between the Epsons and the Canons is pretty close, no matter who's reviews you read. With the quality so close, what it came down to for me was the history of print head clogs on the Epsons and the Canon's faster speed.
--- SER
Just FYI, the Canon i9100 comes with permanent print heads. You can order a replacement head from Canon and replace the carriage yourself, but the print heads aren't embedded in the ink cartridges. Epson heads can be replaced, too, but you have to send the entire printer in; it isn't a DIY job.
--- SER
Canon printers tend to be significantly faster then their same-generation Epson counterparts, and tend to do a little better with color reproduction. Epsons, on the other hand, are much better for longevity and certainly produce better black and white photographic prints.
I've got three printers at home now, and each serves a different function. I'll probably buy an Epson for B/W printing as soon as I can find a place to hide it so my wife doesn't see it. The silly woman thinks we have too many printers as it is.
--- SER
I don't know; I've always been able to find libraries that I needed for Haskell; there are quite a few listed on the Haskell libraries page. It seemed to me, when I was evaluating OCaml, that a lack of libraries bindings or bindings to other language's libraries was not a problem. They've got quite a decent database of extensions at The Camel Humps
I'm mainly a Java and Ruby developer, though, so I may not have stressed tested the availability of Haskell libraries. Java doesn't use libraries; if somebody writes a third-party library for it, Sun re-implements it, poorly, and bundles it with the VM, which effectively kills the original, and often superior, library. And Ruby... well, you just create whatever bindings you need, dynamically, with 'dl'.
--- SER
On what do you base this claim? If you're talking about the GCC options in make.conf, that's entirely optional. I just use the default options -- I did choose the correct architecture as suggested by the comments, but this in no way imparts knowledge of how GCC "actually functions" -- I'm entirely clueless about GCC, and I get along well with Gentoo.
I disagree. USE flags are very useful on a per-system basis, as well. Two examples that I have in make.conf files:
- -X, on a server
- -gnome, on my laptop
Keeps a lot of stuff that I don't use from being compiled.Anyway, the Dremel is great if all you want to do is scour a pattern into the skin of a pumpkin, but none of the bits (that I've been able to find) are long enough to actually cut a hole in an average pumpkin. On top of that, even at the lowest speed, you end up with pumpkin paste and orange mist.
At least, IME. The best tool I've found is indeed one of those cheapo pumpkin carving sets with dayglow handles and rigid, roughly serrated knives -- usually one thick, and one thin. We got one this year that came with a rigid spatula that worked really well, too.
Even so, I wish Dremel would come out with an extra-long, pumpkin-specific bit.
This may be true, but in SQL, NULL != NULL.
This is what I love most about SQL:
and then:And neither query returns anything. Isn't that great? "=" is equality, but only sometimes. That cracks me up.No, we don't, but there is -- arguably -- a lot of benefit to be had from knowing how the technology works, if only to know what it is going to take for someone else to do it. Even if we don't research it, somebody will, and if we don't know how it works, we won't be able to train James Bond in disarming it.
Incidentally, this would be quite nice to have, from a military point of view. Sure, it is expensive, but theoretically, once you have the factory, all you need is some solar panels to produce the stuff. You have to mine Uranium, and fissionables are heavy. If you ignore the cost of getting the factory into orbit (which is a stupid thing to ignore), this is great. Create it right in orbit, drop it on your Axis of Evils, whoever they happen to be at the moment. Heck, assuming you can get the plant small enough, it'd be a real treasure -- it doesn't matter if it isn't making much antimatter, because it can be making it all the time, for free.
Anyway, knowing how to get around with this technology is useful, even if we (hopefully) never actually use it. Security through obscurity is false security.
There are a lot of caveats in my post; for instance, if you're strategically in orbit, there are all sorts of things you can drop on things that are way less expensive than antimatter. Personally, I think there's a reasonable chance that a good number of the 8,000 larger-than-softball objects in low orbit are ceramic balls with some depleted uranium, a tiny radio, simple microprocessor, and some navigational explosives. The only thing that keeps me from being totally paranoid about it is the Discordian truism: Govornments are the kinds of things which, although they do small things badly, do large things badly, too.
Palm has forgotten the mantra of the original developers that made the Palm III such a success -- keep it small. The Tungsten T is just barely carryable, and the newer versions just keep getting bigger. Personally, I'd rather see Palm spend their energy reducing the size of the T series than increasing the features.
Except that everybody who is even a little educated about the matter agrees that first-past-the-post (the US system) is the worst possible voting mechanism, and that any of the proposed changes would be an improvement.
IE, even Approval Voting advocates would accept IRV or Borda if it was the only way to change the system, and vice versa.
--- SER
Hm. I think you misunderstood your dad, or he misremembered his training. I'm sure they taught him to shoot to kill, but not because the enemy is "shooting at your head" while you're shooting at his leg. The real reason is because it's hard enough to hit somebody in a combat situation without trying to shoot hit something with as little surface area as a leg, or arm, or a head. You shoot at the torso, because it gives you the best chance of actually hitting them. And you don't shoot at someone's head, unless you're really close and they aren't moving.
There are exceptions, obviously. With plenty of training and skill, and some decent equipment, good conditions, and sufficient time for aiming, you can place your shots pretty well.
That's how we ended up in this mess in the first place. A large number of people voted for third parties in 2000. We still ended up with a major party in charge, but we ended up with the greater of two evils. It is going to continue this way until we get an alternate voting system, like runoff or approval voting.
It is clear that most of the people who voted for Nader would have preferred Gore to Bush, and the Green party was the leading third party 2000. In voting for Nader, Green voters sabotaged the system (from their own point of views) and cost Gore the election, thus proving -- for those people -- that the American election system does not work. I'd go further and propose that many people who did vote for Gore or Bush would have preferred somebody else, but knew that a vote for a third party in the USA is a waste of a vote. Not only the Greens are disenfranchised by our existing system; Buchanan voters got their preferred second choice this time around, but only because they got lucky that there was massive voting fraud in Florida. Libertarians have been consistently disenfranchised for -- well, forever. The last time we had a third party president elected was in 1860, when Lincoln was elected.
Admittedly, I was part of the problem in 2000; I voted for a third party, too. I won't make that mistake this time around, though. I don't know if Kerry will make a bad president, but I know Bush is a bad one, and I'll take a chance on someone who hasn't proven himself to be incompetent.
On this news, SCO's stock jumped five points as more clueless, mostly stupid investors with learning disabilities threw more of their money away.
Back in '88 I had a Nighthawk that I couldn't work on myself: the engine was mostly inaccessible without disassembling the entire bike, and the electronics were obtuse. On the other hand, I had a Ford LTD that I could take apart with just three tools.
Bikes are no easier to work on than cars; it just depends on which bike (or car) that you buy.
IE has supported PNGs for a long time. It just doesn't support transparency in PNGs.
You would have loved NeXTSTEP. You could drag-and-drop from anything to anything. I think some automatic heuristics in the GUI toolkit itself really helps here, and I'm not surprised that MacOSX inherited this from NeXTSTEP.
The dislike isn't arbitrary. There is considerable resistance in Japan and China to Unicode, in part due to the fact that the ordering of characters is different than the order of established standards. The same is true for East Indian languages (although the objections are rather different).
Unicode is western-centric, a bias that can be seen in the fact that 7-bit ASCII maps one-to-one to UTF-8. Imagine, if you will, if -- rather than a clean 1-1 mapping of ASCII-7 to UTF-8 -- UTF-8 rearranged the characters, so they were ordered:
P e g 6 u l o G K x 1...
These aren't the only objections, but they illustrate that any dislike of Unicode is far from arbitrary.
Ruby does have Unicode support; granted, Ruby strings are not UTF-8 by default, like they are in Java, and you can't write Ruby programs using UTF-8 characters for variable names, and so on, like you can in Java. But Ruby does have basic support for dealing with UTF-8 strings, sufficient for most purposes.
Most of your Java usage, then, is probably invisible to you, being servlets running on websites that you visit.
My only real complaint about Java clients on Linux, at the moment, is the fact that they integrate so poorly. I can't drag-n-drop from KDE into Java apps. Java applications can't make use of things like KParts, and therefore re-implement a lot of wheels, which is tedious for both developers and users.
The VMs have come a long way in terms of speed on both the client and the server, but integration is a pretty major limitation for some people -- heck, I won't even use Gnome apps for the same reason. I'd rather use a shell, where I can at least pipe data between commands.
In any case, let's pretend he's right, for the sake of an argument, and that a microkernel is better than a monolithic kernel. In that case, here's what I predict: somebody in the Minix community will figure out how to leverage the existing Linux drivers and modules, and will produce Minux(tm)... a Linux with the kernel replaced by a Minix microkernel, using the vast number of existing Linux drivers and software. Since we already said that a microkernel is better than a monolithic kernel, this new Minux will rapidly surpass Linux in popularity.
Not. Because we all know that technical superiority doesn't guarantee success (betamax vs. VHS, Linux vs. Windows). However, it is an interesting possibility to think about.
Caveat: I am not a kernel hacker, and it has been a loooong time since my OS theory classes, so I have no idea how feasible something like this would be. I wish I did, because then I'd do it myself, and I'd become the next Linus Torvalds, and then I'd rule the world!!! Bwahahahahaha!!!!
Actually, the sneaker benefit of this technology is that your laptop will steam-press your pants for your ... or, at least, the thighs of your pant legs.
Actually, no... I imply that the compiler should be smart enough to see that a function recurses, and automatically flag it as such. I'm saying that the programmer is having to do work the compiler should be able to do.
Can a function be recursive without being defined as "let rec"? If so, then "let rec" is indeed purely a scoping mechanism, and although I still don't understand how the scoping rules affects the code, I can accept that it may be useful. However, if recursive functions, and only recursive functions, are defined as "let rec", then I propose that the compiler should be able to determine this from the code itself.
What if I want a polymorphic function, that will accept either floats or integers? What if I have n methods that do some operations on numbers... how many methods do I have to write to support both ints and floats? Do I have to copy and paste the contents of the methods, even if they're practically identical?