A good 35mm will last nearly forever. I've been very satisfied with old, manual Nikons (Nikkormat FT2 and Nikon F2) and the Canon AE-1. The Nikons are a bit higher quality, but the Canon is well built. The biggest obstacles to good photography are: (1) the photographer, and (2) the subject(s) - when photographing people. If you're serious about photography, any decent 35mm SLR can produce spectacular results in the hands of a skilled photographer.
"This is a big win for Linux...". While this may indeed be a big win for Linux, I'd just like to point out that free/OSS does not necessarily mean that Linux will be the choice. They could easily decide to standardize on FreeBSD.
Before people get too excited about topics such as SMP, kernel threads, and I/O devices -- it only partially boots on a mainframe emulator. This is a VERY LONG WAYS OFF from asking, "so where can I download the ISO images?".
While I'm one of the "I wish it had explicit delimiters" camp, I settled on the following convention involving comments that seems to work for me.
if x == 10:
# end if
while not done:
# end while
for x in y:
# end for
It's still not quite as getting a quick visual alignment of curly braces (I put my open brace aligned with my close brace), after a little practice it's easy to discern blocks.
I use Visual SlickEdit for my Python development. It has a lexer for Python, but by default there are no file extension mappings to the Python lexer. Easy enough -- I just associate ".py" extension to the Python lexer, and voila - nice color-coded syntax support! BTW, I also use Visual SlickEdit for C/C++, Java, HTML, bat files.
IBM should be more concerned about forgiving itself about OS/2. Granted, I'm not excusing MS, but part of the blame for the OS/2 failure lies squarely on IBM's shoulder.
Remember that the third letter in IBM is "Machines". IBM has always been more interested in selling hardware than software. If IBM provides top-notch support for Linux across their entire hardware line, it'll attract more buyers of their hardware as more and more businesses use Linux.
Here's why Python is a better choice of OO scripting language *for me* (YMMV):
(1) Python code is more obvious about what's happening. Perl has implied arguments that can make it difficult for someone else to maintain. Example: "chomp;". I look at this and wonder: "chomp what?" After reading in Perl docs, I find out that $_ is implied. Not nice.
(2) Python code *tends* to be far more readable, and hence more maintainable. I concede that it is possible to write readable Perl code, but 99% of it that I've seen is not very readable.
(3) I'm a former user of REXX (mostly on OS/2). This is a language that I *really* liked because it was powerful and simple. Since REXX is not readily available to me on the platforms that I use, I now use Python for the same reasons that I used to use REXX. I find that my productivity with scripting languages like REXX and Python to be unsurpassed with any other language.
(4) Python seems to provide more consistency over Perl (and not just syntax/style). I can't recall the specific cases, but Perl tends to have a philosophy of being able to do the same thing many different ways. Python, on the other hand, tends to not have as many choices. For me, this makes Python code more maintainable.
(5) Writing OO code in Python is more natural and cleaner to me than in Perl.
Myths 1) NT == IDE (can use CLI makes on NT) 2) Linux == CLI (can use IDE on Linux/Unix)
Advantages of *any* unix flavor: 1) Client/Server nature of X (can sit at your workstation and work on any other unix box transparently. no need for pcAnywhere) 2) Industrial strength "kill" (i can issue kill -9 [pid] and *know* that the process will die) 3) More sophisticated shells (BASH, C shell, Korn shell, Bourne shell all leave cmd.exe in the dirt). Though one can get these equivalents on Windows, they're there on Unix. 4) lsof (view which processes have files open -- very handy on occasion)
Advantages of NT: 1) Tightly integrated toolset for MS development tools.
Tools/Utilities: 1) The tools/utilities such as vi, emacs, sed, awk, etc. can all be obtained for Windows. However, the Unix versions typically are more full-featured. 2) Editors are definitely a matter of personal preference. Personally, I'm no fan of emacs. There's a nice GUI editor called "CoolEdit" (http://cooledit.sourceforge.net/) that only requires Xlib. See above advantage of the client/server nature of X. Commercial editors like Visual Slickedit (my favorite) is available on Windows, most flavors of Unix, and other platforms (OS/390 even). 3) I've come to the conclusion that it's often better to stick with scripting languages like Perl or Python (my favorite) instead of writing shell scripts or batch files. They're more powerful, usually more readable (at least in the case of Python), and definitely more portable. 4) Using *multiple* compilers on your source is often advantageous since one compiler may catch some things that another will not (as well as giving a check on compiler dependencies).
Re-read my post: I said that SQL Server "has not" supported row-level locks and that "(it may now -- I don't know)". Historically, it has not. Remember my comment about being "battle-tested" over time.
I guess that we have different definitions of "enterprise" apps. I think of "enterprise" apps as those that can support more than 5,000 or 10,000 simultaneous users doing line-of-business, serious stuff. What's your definition of "enterprise" apps?
A lot of the limitations of SQL Server are really limitations of the OS and the hardware. The reliability and failover capabilities of "big iron" hardware and OSs cannot be matched by anything like PCs.
Your comment about not supporting raw I/O is well taken. It may not be advantageous in all cases -- good point.
I don't doubt that SQL Server may work better in some applications. Use the right tool for the job (experience with a product can also be a big factor).
I was not trying to give a knee-jerk flame against Microsoft or SQL Server. I even mention some of the same problems for other OSs like Linux, and PCs in general. The response was prompted by the question: "so why isn't SQL Server adequate for betting the company's jewels/enterprise ready". I gave some reasons.
If the question were "why not PostgreSQL?" I would give a similar response. Chill out.
Sheesh, once you throw those away what are you left with? Here are a few observations:
SQL Server is not battle-tested for big, mission-critical apps
SQL Server runs only on NT -- need I say more?
SQL Server has its roots in running departmental apps. Oracle and DB2 run enterprise apps.
SQL Server is probably lacking in many of the high-availability areas (on-line backup and restore for example)
SQL Server has not supported row-level locking (it may now -- I don't know)
SQL Server doesn't support raw I/O because NT doesn't support raw I/O
SQL Server is nowwhere to be found on big iron (of any sorts) -- sometimes you just gotta have big iron.
DB2 runs on SP2 RS/6000 hardware -- can you say *big* time server? SP2 clusters can be configured with nodes of S80 enterprise servers. There is a special version of DB2 that runs on these parallel machines. NT (and Linux) are *nowwhere* close to matching this.
DB2 (and Oracle) run on hardware and OSs that consistently run 24x7 for months (if not a year) between IPLs (reboot).
DB2 should definitely be added to the list of "bet the company's jewels" RDBMS products. This is the database of choice for many banks and financial institutions. BTW, the company that provides data processing for roughly 40% of *ALL* mutual funds stores *your* data in DB2 (mainframe flavor) -- I used to work for them.
Slashdot Mirror
A good 35mm will last nearly forever. I've been very satisfied with old, manual Nikons (Nikkormat FT2 and Nikon F2) and the Canon AE-1. The Nikons are a bit higher quality, but the Canon is well built. The biggest obstacles to good photography are: (1) the photographer, and (2) the subject(s) - when photographing people. If you're serious about photography, any decent 35mm SLR can produce spectacular results in the hands of a skilled photographer.
"This is a big win for Linux...". While this may indeed be a big win for Linux, I'd just like to point out that free/OSS does not necessarily mean that Linux will be the choice. They could easily decide to standardize on FreeBSD.
to compile the linux kernel on this thing.
to have a Beowolf cluster -- oh never mind!
Before people get too excited about topics such as SMP, kernel threads, and I/O devices -- it only partially boots on a mainframe emulator. This is a VERY LONG WAYS OFF from asking, "so where can I download the ISO images?".
http://www-1.ibm.com/servers/eserver/zseries/os/li nux/lcds/index.html
While I'm one of the "I wish it had explicit delimiters" camp, I settled on the following convention involving comments that seems to work for me.
if x == 10:
# end if
while not done:
# end while
for x in y:
# end for
It's still not quite as getting a quick visual alignment of curly braces (I put my open brace aligned with my close brace), after a little practice it's easy to discern blocks.
YMMV!
I use Visual SlickEdit for my Python development. It has a lexer for Python, but by default there are no file extension mappings to the Python lexer. Easy enough -- I just associate ".py" extension to the Python lexer, and voila - nice color-coded syntax support! BTW, I also use Visual SlickEdit for C/C++, Java, HTML, bat files.
IBM should be more concerned about forgiving itself about OS/2. Granted, I'm not excusing MS, but part of the blame for the OS/2 failure lies squarely on IBM's shoulder.
Remember that the third letter in IBM is "Machines". IBM has always been more interested in selling hardware than software. If IBM provides top-notch support for Linux across their entire hardware line, it'll attract more buyers of their hardware as more and more businesses use Linux.
Here's why Python is a better choice of OO scripting language *for me* (YMMV):
(1) Python code is more obvious about what's happening. Perl has implied arguments that can make it difficult for someone else to maintain. Example: "chomp;". I look at this and wonder: "chomp what?" After reading in Perl docs, I find out that $_ is implied. Not nice.
(2) Python code *tends* to be far more readable, and hence more maintainable. I concede that it is possible to write readable Perl code, but 99% of it that I've seen is not very readable.
(3) I'm a former user of REXX (mostly on OS/2). This is a language that I *really* liked because it was powerful and simple. Since REXX is not readily available to me on the platforms that I use, I now use Python for the same reasons that I used to use REXX. I find that my productivity with scripting languages like REXX and Python to be unsurpassed with any other language.
(4) Python seems to provide more consistency over Perl (and not just syntax/style). I can't recall the specific cases, but Perl tends to have a philosophy of being able to do the same thing many different ways. Python, on the other hand, tends to not have as many choices. For me, this makes Python code more maintainable.
(5) Writing OO code in Python is more natural and cleaner to me than in Perl.
Myths
1) NT == IDE (can use CLI makes on NT)
2) Linux == CLI (can use IDE on Linux/Unix)
Advantages of *any* unix flavor:
1) Client/Server nature of X (can sit at your workstation and work on any other unix box transparently. no need for pcAnywhere)
2) Industrial strength "kill" (i can issue kill -9 [pid] and *know* that the process will die)
3) More sophisticated shells (BASH, C shell, Korn shell, Bourne shell all leave cmd.exe in the dirt). Though one can get these equivalents on Windows, they're there on Unix.
4) lsof (view which processes have files open -- very handy on occasion)
Advantages of NT:
1) Tightly integrated toolset for MS development tools.
Tools/Utilities:
1) The tools/utilities such as vi, emacs, sed, awk, etc. can all be obtained for Windows. However, the Unix versions typically are more full-featured.
2) Editors are definitely a matter of personal preference. Personally, I'm no fan of emacs. There's a nice GUI editor called "CoolEdit" (http://cooledit.sourceforge.net/) that only requires Xlib. See above advantage of the client/server nature of X. Commercial editors like Visual Slickedit (my favorite) is available on Windows, most flavors of Unix, and other platforms (OS/390 even).
3) I've come to the conclusion that it's often better to stick with scripting languages like Perl or Python (my favorite) instead of writing shell scripts or batch files. They're more powerful, usually more readable (at least in the case of Python), and definitely more portable.
4) Using *multiple* compilers on your source is often advantageous since one compiler may catch some things that another will not (as well as giving a check on compiler dependencies).
Re-read my post: I said that SQL Server "has not" supported row-level locks and that "(it may now -- I don't know)". Historically, it has not. Remember my comment about being "battle-tested" over time.
I guess that we have different definitions of "enterprise" apps. I think of "enterprise" apps as those that can support more than 5,000 or 10,000 simultaneous users doing line-of-business, serious stuff. What's your definition of "enterprise" apps?
A lot of the limitations of SQL Server are really limitations of the OS and the hardware. The reliability and failover capabilities of "big iron" hardware and OSs cannot be matched by anything like PCs.
Your comment about not supporting raw I/O is well taken. It may not be advantageous in all cases -- good point.
I don't doubt that SQL Server may work better in some applications. Use the right tool for the job (experience with a product can also be a big factor).
I was not trying to give a knee-jerk flame against Microsoft or SQL Server. I even mention some of the same problems for other OSs like Linux, and PCs in general. The response was prompted by the question: "so why isn't SQL Server adequate for betting the company's jewels/enterprise ready". I gave some reasons.
If the question were "why not PostgreSQL?" I would give a similar response. Chill out.
Sheesh, once you throw those away what are you left with? Here are a few observations:
SQL Server is not battle-tested for big, mission-critical apps
SQL Server runs only on NT -- need I say more?
SQL Server has its roots in running departmental apps. Oracle and DB2 run enterprise apps.
SQL Server is probably lacking in many of the high-availability areas (on-line backup and restore for example)
SQL Server has not supported row-level locking (it may now -- I don't know)
SQL Server doesn't support raw I/O because NT doesn't support raw I/O
SQL Server is nowwhere to be found on big iron (of any sorts) -- sometimes you just gotta have big iron.
DB2 runs on SP2 RS/6000 hardware -- can you say *big* time server? SP2 clusters can be configured with nodes of S80 enterprise servers. There is a special version of DB2 that runs on these parallel machines. NT (and Linux) are *nowwhere* close to matching this.
DB2 (and Oracle) run on hardware and OSs that consistently run 24x7 for months (if not a year) between IPLs (reboot).
Is this enough evidence?
DB2 should definitely be added to the list of "bet the company's jewels" RDBMS products. This is the database of choice for many banks and financial institutions. BTW, the company that provides data processing for roughly 40% of *ALL* mutual funds stores *your* data in DB2 (mainframe flavor) -- I used to work for them.