While data going back to 1973 is valid, the only way to identify a trend would be to go back much, much farther (ice cores can do this). The trends over the last 10,000 years, for example, may go along ways to explaining things, to disprove or prove things.
Umm, why would you want to import a database into a spreadsheet? Just leave it in a database where it belongs. It is this insistance of folks to use spreadsheets for keeping databases that completely drives me nuts. It's the wrong tool for the job! Having said that, we do desparately need a nice Access alternative in Linux for building easy, simple apps that use a real sqlite or mysql backend. Openoffice.org Base is getting closer but still not quite it yet.
In short your spreadsheet is a nice toy, but not really up to the task of being a database for records, books, or anything else.
In radio controlled stuff these days, Lithium Polymer batteries are now widely used because of their high capacity and high amperage abilities. But they are highly volatile. They can explode sometimes, especially when charged incorrectly, or if they are shorted out. Search google for "lipo fire" and you'll find some pretty interesting pyrotechnic videos. Also google video has a few. But from what I understand capacitors are more dangerous than batteries for reasons other than fires and explosions. The voltage that can come off of a cap can kill a person. In the case of an auto accident, chemical fires can probably be dealt with by emergency personel. But having an accidental discharge of a large capacitor could kill emergency responders as well as the people trapped in such an auto.
This is exactly what CentOS does. They ship a new image every so often that has all the updates and call it version 4.3, for example. Works well and the updates are transparent and work with every version. Periodically we update our net install image so that we can do a network install of the latest patch level. Plus we maintain an internal yum mirror for security updates.
You're right. I'm not remembering correctly. I was probably closer to that age when I read them. That's a long time ago so I'm pretty hazy...
I'm with you on the Encyclopedia Brown and Hardy Boys. They were very good. At some point I also remember reading a series (along the same vein) called "The Three Investigators"
As I submitted my last comment, I remembered that during this time when the choose your own adventure books were all the rage, I was showed a bunch of very well-written books from a Canadian author named Gordan Korman. These books are targeted to teenagers mainly, and are at a much more advanced reading level than the choose your own adventure books. But kids are a lot smarter than they look and they do take well to intelligent, well-written fiction. Korman's books include a number of series aimed at, I'd say 12 year olds, called the McDonald Hall series, and then a bunch of very good books aimed at slightly older teenagers including "Losing Joe's Place," "A Semester in the Life of a Garbage Bag," "Don't Care High," "No Coins Please," and so forth. Great books. I also remember reading "Interstellar Pig" by William Sleater. Around that time I was also introduced to a great collection of science fiction short stories by various famous authors, edited by Asimov. I can't remember the title of this book, but it has some great thinker stories in it.
In short there are *lots* of good books out there that are intellectually stimulating as well as entertaining and won't insult kids' intelligence. Although perhaps the age of shoot-em-up games and FPS have ruined kids for that kind of thing. So maybe CYOA's 10-page stories will be well-received.
I absolutely hated Choose Your Own Adventure books when I was in junior high. Instead of spending 200-300 pages on plot and character development, these books were basically just a serious of 4-page stories. Even if you did find a longer path through the book there was just no substance there to keep your attention. Besides, I ran out of fingers trying to mark all my places so I could go back whenever I died. Basically the books had all the plot and storyline of a first-person shooter game without any of the graphics or weapons.
Milter offers out-of-process access through a standard api into every step of the smtp process, from connection, to envelopes, to headers, messages, etc. The API is clear, well-defined, and modular, with bindings for many langages. Writing an SPF filter is just a matter of a short python script. Because milter uses a protocol over a socket, milters can run on other machines, or run locally. It is very flexible. Because milter is so closely tied to the smtp process, your filters needn't implement any protocol parsing and can just implement filter parts you need. Milters can add headers, remove headers, access the mime parts of the body (adding, editing, or removing), all without any special decoding logic. It is a great system. Many folks have asked postfix to implement this, but the postfix developers so far have shown little interest (and it may in fact not be compatible with the postfix architecture).
The biggest reason I switched away from sendmail was I did lose data because of mbox file corruption on two occasions. Maildir is much better at protecting against that.
Sendmail really doesn't care what format the mail is ultimately stored in; that's not sendmail's job anyway. That's the job of the delivery agent, which for most people is procmail. Procmail can deliver to either mbox or Maildir. I've been happily using sendmail and delivering to Maildir boxes for several years now. Works great.
There is one feature that keeps me on Sendmail and probably will for the foreseeable future. That is the sendmail milter API. Plugging defangers, antivirus scanners, and spam scanners into the mail system using milter is by the far the best solution I have seen. It's fast and can operate at any level of the mail processing process, from connection to envelopes to the message body itself. Postfix has no such comparable system. While many folks do use things like amavisd, they don't quite compare as amavis essentially has to speak full smtp (well lmtp anyway). This means usually that's it is much harder to perform early filtering, like during the HELO stage of smtp.
Further I'm also sceptical of QMail and the brash claims made by QMail affectionados, although his Maildir idea was brilliant. So for my home machine where I just want simplicity over power, I am running Postfix. Once postfix has a milter API, I'll switch to it across the board. But in the meantime my at-work servers will run sendmail.
I think much of OS X's ram-hungriness comes from the fact that outside of the system frameworks, there is very little utilization of shared libraries among the different applications. Each app bundle is largely self-contained with its own shared libraries. Granted most apps that ship with OS X (from apple) just access the shared frameworks in/Library/Frameworks and have few other dependencies in their bundles. But start adding apps like MS Word, Firefox, OpenOffice, etc, and you'll start having multiple copies of various libraries loaded. The app bundle system is very simple and reliable, but because of the shared library issue, you'll always need more ram when running these apps on OS X than Windows or Linux.
Definitely 1 GB is a minimum amount of RAM needed for OS X Tiger these days. That is quite sad when you think about it, but RAM is cheap so I'm not too concerned about it. Apple has always shipped their machines short on RAM, hoping you'll pay ridiciulous amounts of money for their official RAM upgrades.
Oh am I not supposed to record music from Rhapsody? Someone forgot to tell me. Sure it took an hour per album, but now I have a few shiny oggs. Too bad rhapsody refuses to upgrade their firefox plugin to run on Firefox 1.5 on linux. Back to allofmp3.com.
Just had to go to the store and check one out. Good news is the keyboard is not as bad as it looks. It feels quite good actually. The screen is vivid and beautiful--if you have perfect light conditions. Otherwise it is glare city. And the size isn't too bad. Bigger than the 12" and heavier too (not by much). But overall the unit has a fisher-price feel (impression, not physical quality) to it. The chicklet keyboard gives the whole thing a real Commodore PET-like quality to it. Definitely not a unit a professional would want to carry around. For home use it would be fine. Cheaper than an equivalent Dell, but with the OS X goodness.
I've all but decided I'll have to buy a Macbook Pro 15".
I look forward to seeing these laptops myself in the stores. From the pictures, I don't like the look of the keyboard at all. And the glossy screen just sucks, especially because I'll be using it in a florescent-lit office most of the time. I don't want to have to constantly counter the glare. And what about bright sunlight? And the fact that Apple still hasn't done anything about the thermal paste problem is worrisome. Maybe by the time I'm in the market for a new machine about November these issues will be fixed. And although I don't really want a bigger laptop than my 12" (the 13" would probably be fine), I guess I'll probably get the 15" Pro since I just don't like the white look (not to mention the keyboard and screen unknowns). I already know what the 15" MacBook Pro is like. Looks like Apple no longer sells any subnotebooks. A shame.
Yes I would. First off, working in private for a year on open source code without contributing the patches as you go is just stupid. You are in essence forking the code. So you're not contributing at all.
This is almost exactly what Apple has done to many open source components, although they do strive to keep them in sync. But they are forks nonetheless. And very few people benefit from forks. Yes you can use open source in a closed and proprietary way. I'd much rather see apple maintain patchsets against the official codebases. From my admin point of view, Apple's forks make my administration of the servers quite difficult. It is unlikely I will ever use Apple's products in a server capacity again because of this (the real problem was that OS X Server is just not that stable but I can't diagnose and replace the parts because of Apple's development model).
Sure, but Apple's corporate culture used to be more of a community of hackers just trying to make the world a better place and to a certain extent they've tried to keep up that impression.
Apple is quicker to respond than, say Microsoft. And they have done good things with WebKit. However it's unclear to me how much of Apple's good behavior with regards to WebKit (getting patches etc) is because of the pressure from open source groups and how much is due to Apple being a good citizen.
But at the end of the day, Apple is a proprietary software vendor. Apple never was an open source company. But they did grasp how to utilize open source to their advantage, but it was always in a way that was really not quite in the spirit of the open source community. Yes the source code was always available for Darwin and the pieces of OS X. But rarely in patch form and often not buildable without tracking down internal header files. Working with Apple's build of OpenLDAP in Panther Server really soured me to Apple's commitment to Open Source. While the code was there, it was difficult to see just what they had changed and very hard to take their changes and apply them to the newer version of OpenLDAP. A great example of how you can use open source in a very closed way.
So this doesn't come as any surprise to me. And I really don't have any ill will towards Apple, as I understand their position they are in. But I don't agree with the position they have taken but that is their perogative.
Apple's web site indicates this new model has a stunning glossy screen. Am I the only one that hates these new glossy screens. They reflect glare and just look bad. The screen on the MacBook Pro isn't glossy. Why does the MacBook need a glossy screen?
Not as such, no. OS X is not really based on FreeBSD per se. The Xnu kernel has a BSD layer that implements some of the FreeBSD kernel api (using modified FreeBSD kernel code), and indeed much of the OS X system depends on the BSD layer. But to say that OS X is based on FreeBSD and is a BSD derivative is just not accurate.
Now who's spouting FUD...SWT isn't designed to be that great of a framework, it's designed to be as low-level as is possible in Java. JFace is built on top of SWT and is designed to be much more developer friendly. Comparing SWT to Swing is like comparing AWT to Swing. If you want an apples to apples comparison, talk about JFace, not SWT.
Hmm. Seems like you just confirmed what I said. SWT isn't designed to be a great UI framework. And yes, it is just a glorified AWT library. As for comparing Swing to SWT, well, I did not originate that comparison; I was responding to it. But thanks for your post. You've successfully invalidated the original poster's point, which is what I was also trying to do.
Perhaps Java 6 will solve everything but to believe that is to ignore those same promises made with every release. Besides which Java 6 isn't even out yet.
You tell me. Java 6 may not be out but you can download the release candidates right now and try it out. Then you can give Sun feedback on the issues with Java and Swing that still need to be worked on. Until you have tried Java 6's Swing implementation it is just FUD. Seems to me like most slashdotters are determined to continue to hate Swing for the foreseable future, even if Java 6 addresses every one of these concerns.
Yes file chooser integration is an issue. I can't remember if Swing under Java 6 implements native dialogs or not.
Slashdot Mirror
Whatever happened to doing whatever you wanted unless it hurt someone else?
No, I don't think that was ever part of the constitution. There was never a cart-blanche do-anything-you-want provision.
While data going back to 1973 is valid, the only way to identify a trend would be to go back much, much farther (ice cores can do this). The trends over the last 10,000 years, for example, may go along ways to explaining things, to disprove or prove things.
Umm, why would you want to import a database into a spreadsheet? Just leave it in a database where it belongs. It is this insistance of folks to use spreadsheets for keeping databases that completely drives me nuts. It's the wrong tool for the job! Having said that, we do desparately need a nice Access alternative in Linux for building easy, simple apps that use a real sqlite or mysql backend. Openoffice.org Base is getting closer but still not quite it yet.
In short your spreadsheet is a nice toy, but not really up to the task of being a database for records, books, or anything else.
In radio controlled stuff these days, Lithium Polymer batteries are now widely used because of their high capacity and high amperage abilities. But they are highly volatile. They can explode sometimes, especially when charged incorrectly, or if they are shorted out. Search google for "lipo fire" and you'll find some pretty interesting pyrotechnic videos. Also google video has a few. But from what I understand capacitors are more dangerous than batteries for reasons other than fires and explosions. The voltage that can come off of a cap can kill a person. In the case of an auto accident, chemical fires can probably be dealt with by emergency personel. But having an accidental discharge of a large capacitor could kill emergency responders as well as the people trapped in such an auto.
This is exactly what CentOS does. They ship a new image every so often that has all the updates and call it version 4.3, for example. Works well and the updates are transparent and work with every version. Periodically we update our net install image so that we can do a network install of the latest patch level. Plus we maintain an internal yum mirror for security updates.
I demand to have serif fonts again here on slashdot. I also demand to put the scores near the comment title.
I agree, particularly about the scores stuff. Time to hack the CSS and use a local style sheet.
No, Interstellar Pig was a great non-CYOA book. The characters, yes, were in a choose-your-own adventure of a very real (well, fictional ;).
You're right. I'm not remembering correctly. I was probably closer to that age when I read them. That's a long time ago so I'm pretty hazy...
I'm with you on the Encyclopedia Brown and Hardy Boys. They were very good. At some point I also remember reading a series (along the same vein) called "The Three Investigators"
As I submitted my last comment, I remembered that during this time when the choose your own adventure books were all the rage, I was showed a bunch of very well-written books from a Canadian author named Gordan Korman. These books are targeted to teenagers mainly, and are at a much more advanced reading level than the choose your own adventure books. But kids are a lot smarter than they look and they do take well to intelligent, well-written fiction. Korman's books include a number of series aimed at, I'd say 12 year olds, called the McDonald Hall series, and then a bunch of very good books aimed at slightly older teenagers including "Losing Joe's Place," "A Semester in the Life of a Garbage Bag," "Don't Care High," "No Coins Please," and so forth. Great books. I also remember reading "Interstellar Pig" by William Sleater. Around that time I was also introduced to a great collection of science fiction short stories by various famous authors, edited by Asimov. I can't remember the title of this book, but it has some great thinker stories in it.
In short there are *lots* of good books out there that are intellectually stimulating as well as entertaining and won't insult kids' intelligence. Although perhaps the age of shoot-em-up games and FPS have ruined kids for that kind of thing. So maybe CYOA's 10-page stories will be well-received.
I absolutely hated Choose Your Own Adventure books when I was in junior high. Instead of spending 200-300 pages on plot and character development, these books were basically just a serious of 4-page stories. Even if you did find a longer path through the book there was just no substance there to keep your attention. Besides, I ran out of fingers trying to mark all my places so I could go back whenever I died. Basically the books had all the plot and storyline of a first-person shooter game without any of the graphics or weapons.
Milter offers out-of-process access through a standard api into every step of the smtp process, from connection, to envelopes, to headers, messages, etc. The API is clear, well-defined, and modular, with bindings for many langages. Writing an SPF filter is just a matter of a short python script. Because milter uses a protocol over a socket, milters can run on other machines, or run locally. It is very flexible. Because milter is so closely tied to the smtp process, your filters needn't implement any protocol parsing and can just implement filter parts you need. Milters can add headers, remove headers, access the mime parts of the body (adding, editing, or removing), all without any special decoding logic. It is a great system. Many folks have asked postfix to implement this, but the postfix developers so far have shown little interest (and it may in fact not be compatible with the postfix architecture).
Sendmail really doesn't care what format the mail is ultimately stored in; that's not sendmail's job anyway. That's the job of the delivery agent, which for most people is procmail. Procmail can deliver to either mbox or Maildir. I've been happily using sendmail and delivering to Maildir boxes for several years now. Works great.
There is one feature that keeps me on Sendmail and probably will for the foreseeable future. That is the sendmail milter API. Plugging defangers, antivirus scanners, and spam scanners into the mail system using milter is by the far the best solution I have seen. It's fast and can operate at any level of the mail processing process, from connection to envelopes to the message body itself. Postfix has no such comparable system. While many folks do use things like amavisd, they don't quite compare as amavis essentially has to speak full smtp (well lmtp anyway). This means usually that's it is much harder to perform early filtering, like during the HELO stage of smtp.
Further I'm also sceptical of QMail and the brash claims made by QMail affectionados, although his Maildir idea was brilliant. So for my home machine where I just want simplicity over power, I am running Postfix. Once postfix has a milter API, I'll switch to it across the board. But in the meantime my at-work servers will run sendmail.
Not sure why my post was rated funny, but oh well. Karma is karma.
7.0 release candidates have been working great for me for months now. Of course that is with stock drivers; no proprietary nvidia driver or anything.
I think much of OS X's ram-hungriness comes from the fact that outside of the system frameworks, there is very little utilization of shared libraries among the different applications. Each app bundle is largely self-contained with its own shared libraries. Granted most apps that ship with OS X (from apple) just access the shared frameworks in /Library/Frameworks and have few other dependencies in their bundles. But start adding apps like MS Word, Firefox, OpenOffice, etc, and you'll start having multiple copies of various libraries loaded. The app bundle system is very simple and reliable, but because of the shared library issue, you'll always need more ram when running these apps on OS X than Windows or Linux.
Definitely 1 GB is a minimum amount of RAM needed for OS X Tiger these days. That is quite sad when you think about it, but RAM is cheap so I'm not too concerned about it. Apple has always shipped their machines short on RAM, hoping you'll pay ridiciulous amounts of money for their official RAM upgrades.
Oh am I not supposed to record music from Rhapsody? Someone forgot to tell me. Sure it took an hour per album, but now I have a few shiny oggs. Too bad rhapsody refuses to upgrade their firefox plugin to run on Firefox 1.5 on linux. Back to allofmp3.com.
Just had to go to the store and check one out. Good news is the keyboard is not as bad as it looks. It feels quite good actually. The screen is vivid and beautiful--if you have perfect light conditions. Otherwise it is glare city. And the size isn't too bad. Bigger than the 12" and heavier too (not by much). But overall the unit has a fisher-price feel (impression, not physical quality) to it. The chicklet keyboard gives the whole thing a real Commodore PET-like quality to it. Definitely not a unit a professional would want to carry around. For home use it would be fine. Cheaper than an equivalent Dell, but with the OS X goodness.
I've all but decided I'll have to buy a Macbook Pro 15".
I look forward to seeing these laptops myself in the stores. From the pictures, I don't like the look of the keyboard at all. And the glossy screen just sucks, especially because I'll be using it in a florescent-lit office most of the time. I don't want to have to constantly counter the glare. And what about bright sunlight? And the fact that Apple still hasn't done anything about the thermal paste problem is worrisome. Maybe by the time I'm in the market for a new machine about November these issues will be fixed. And although I don't really want a bigger laptop than my 12" (the 13" would probably be fine), I guess I'll probably get the 15" Pro since I just don't like the white look (not to mention the keyboard and screen unknowns). I already know what the 15" MacBook Pro is like. Looks like Apple no longer sells any subnotebooks. A shame.
Yes I would. First off, working in private for a year on open source code without contributing the patches as you go is just stupid. You are in essence forking the code. So you're not contributing at all.
This is almost exactly what Apple has done to many open source components, although they do strive to keep them in sync. But they are forks nonetheless. And very few people benefit from forks. Yes you can use open source in a closed and proprietary way. I'd much rather see apple maintain patchsets against the official codebases. From my admin point of view, Apple's forks make my administration of the servers quite difficult. It is unlikely I will ever use Apple's products in a server capacity again because of this (the real problem was that OS X Server is just not that stable but I can't diagnose and replace the parts because of Apple's development model).
Sure, but Apple's corporate culture used to be more of a community of hackers just trying to make the world a better place and to a certain extent they've tried to keep up that impression.
Apple is quicker to respond than, say Microsoft. And they have done good things with WebKit. However it's unclear to me how much of Apple's good behavior with regards to WebKit (getting patches etc) is because of the pressure from open source groups and how much is due to Apple being a good citizen.
But at the end of the day, Apple is a proprietary software vendor. Apple never was an open source company. But they did grasp how to utilize open source to their advantage, but it was always in a way that was really not quite in the spirit of the open source community. Yes the source code was always available for Darwin and the pieces of OS X. But rarely in patch form and often not buildable without tracking down internal header files. Working with Apple's build of OpenLDAP in Panther Server really soured me to Apple's commitment to Open Source. While the code was there, it was difficult to see just what they had changed and very hard to take their changes and apply them to the newer version of OpenLDAP. A great example of how you can use open source in a very closed way.
So this doesn't come as any surprise to me. And I really don't have any ill will towards Apple, as I understand their position they are in. But I don't agree with the position they have taken but that is their perogative.
Apple's web site indicates this new model has a stunning glossy screen. Am I the only one that hates these new glossy screens. They reflect glare and just look bad. The screen on the MacBook Pro isn't glossy. Why does the MacBook need a glossy screen?
Not as such, no. OS X is not really based on FreeBSD per se. The Xnu kernel has a BSD layer that implements some of the FreeBSD kernel api (using modified FreeBSD kernel code), and indeed much of the OS X system depends on the BSD layer. But to say that OS X is based on FreeBSD and is a BSD derivative is just not accurate.
Now who's spouting FUD...SWT isn't designed to be that great of a framework, it's designed to be as low-level as is possible in Java. JFace is built on top of SWT and is designed to be much more developer friendly. Comparing SWT to Swing is like comparing AWT to Swing. If you want an apples to apples comparison, talk about JFace, not SWT.
Hmm. Seems like you just confirmed what I said. SWT isn't designed to be a great UI framework. And yes, it is just a glorified AWT library. As for comparing Swing to SWT, well, I did not originate that comparison; I was responding to it. But thanks for your post. You've successfully invalidated the original poster's point, which is what I was also trying to do.
Perhaps Java 6 will solve everything but to believe that is to ignore those same promises made with every release. Besides which Java 6 isn't even out yet.
You tell me. Java 6 may not be out but you can download the release candidates right now and try it out. Then you can give Sun feedback on the issues with Java and Swing that still need to be worked on. Until you have tried Java 6's Swing implementation it is just FUD. Seems to me like most slashdotters are determined to continue to hate Swing for the foreseable future, even if Java 6 addresses every one of these concerns.
Yes file chooser integration is an issue. I can't remember if Swing under Java 6 implements native dialogs or not.