Well, this is purely subjective; I've been using a laptop as my main PC for >2 yrs now. And yes, I am a programmer and yes I spend >>8 hrs in front of a PC. The reason? I spend >>8 hrs in front of a PC: which means, I would like to be in control of my environment during that time, not the PC. I can work on my laptop at work, at home, on the road in an airplane, out in the balcony in this awesome weather we've been having, on my couch, etc, etc.
Yes, laptops are more cramped (I have a MS Natural Keyboard hooked up to mine right now), but they are not necessarily slower than a desktop if they're beefy enough (RAM is important as the minute they hit a slow-ass 2.5" HD they slow down a lot) and an LCD screen is easier on the eyes for long periods of time, than even a kick ass CRT.
However, you're right, I too would like a VGA-in port. I have a coupla small boxes doing server work (NAT, etc) and having those ugly old CRTs around cramps my style:-)...
No, you got it wrong. Shipping is expensive but it's not necessarily more expensive to ship, say a book, from the publisher's factory to say B&N's distribution center to a B&N store than to ship it from the factory to an Amazon warehouse to the customer's doorstep. You would think the first route is cheaper (and it is), but not necessarily so...
What you are missing is two somethings called inventory and opportunity costs. When Barnes & Noble buys X number of books, hoping to sell, say 0.1X and planning to return 0.9X, it amortizes the logistic costs of returning 0.9X books into the profit margins of the 0.1X that it will sell (actual percentages are not as lop-sided but not too far off). Amazon on the other hand may not have to; so in the end, they could sell cheaper and ship directly...
The problem with the brick model is that B&N ties up a lot of cash up front to buy X books. Which means it's losing potential return from these monies that it could have invested elsewhere (the stock market, for instance, ha-ha; in reality better-selling stock, Harry Potter books for example). The first cost is the inventory cost. The lost profits from investing elsewhere is the opportunity cost.
Now, the Dell model of doing business is zero (actually *negative*) inventory cost: the customer has *pre-paid* his computer's components when they enter Dell's factories for assembly. That extra cash (billions of $$$ worth) Dell can use to agressively invest, expand, do whatever on earth it wants. More importantly, near-zero inventory means that Dell can change model lines on a dime. It's an agressive, ultra-efficient PC-making jugernaut.
Amazon on the other hand, cannot use the Dell model and still try to stock every book in existence. Doing so means that it's tying up cash (see above) and warehouse space for low-selling items. So, Amazon has to try and do what retailers do already: aggressively manage its supply chain for that top-10% of items that bring in the majority of the profits. Not try to be the freaking Library of Congress via 1-Click (btw, I am a loyal Amazon customer and I love their service; it just doesn't make any logistical sense).
Yeah, it's a tough problem; Supply chain optimization pushes modern computing hardware and software to its limits, and there's still a long way to go. Oh, did I mention my company is hiring? I need that referrer cash, so drop me a line if you're interested (Atlanta; very, very good C++, Java required).
Man... I love writing code in Python... it is fun as hell (OTOH, I also write awk, ksh, a coupla obscure SPLs you never heard of, so it's probably a bad comparison:-). And the truth is, you can be "dirty" in Python: do things the quick and easy way, instead of the proper OOP way. But, python allows you to quickly read even through bad code. And its ability to be dirty allows you to refactor such bad code easily.
Always, always, good code comes from good coders. A good language though, a) doesn't throw away the key of what the code does *cough*Perl*cough*, and b) allows you still enough flexibility to fix code, hack things together fast, etc *cough*Java*cough*.
Don't expect all of Perl's bells and whistles in Python: Guido doesn't want to pollute the language with equivalent ways of doing things, which makes perfect sense to me: helps readability, and forces everybody to strive towards increasing performance and features in the same 'niche' of code. But there's also *plenty* of power in the language and there is a very big toolset to work from...
In all truthfullness, you shouldn't: Java is faster than Python, and servlets kick ass.
But say you wanted to be able to extend your servlet code, poke at live servlets, or get a lot of 'dirty' information out quickly (quickly as in development time). You can go to jython.org and grab a fully compliant Python interpreter implemented in Java. Presto, you got yourself a 4GL over your Java code. You can go google for JPE, a Java-Python bridge and go load Python extensions in C/C++ (much easier, IMHO than JNI) and talk to Python from Java and vice versa. Both Jython and JPE allow you to extend Python from Java and vice versa. That kicks ass...
Java has its place (that layer of apps just above C/C++) and so does Python (the layer on top of Java). The really great thing is that you won't have to switch mindsets. Python is clean, consistent, and really, really easy to write (much more so than Java, again IMHO).
Again, IMHO, I'd much rather prototype code in Python, work on the design, see what my design is missing, where I have to plug holes, and I can do so really quickly and easily (Python allows you to be more dirty than Java; multiple inheritance, writeable namespaces, exec(), etc...) and then I can profile the code (profiler comes with the std library) and extend the performance-bound parts in C/C++, again very easily. NumPy for example includes all of LINPACK: you get really great C/Fortran speed in numerical functions, but you get to use a RAD language.
Try it, you'll like it. Damn, that should be the Python slogan:-)...
Hmmm... Stack in Python... really hard... mind boggles:
Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> z = [1, 2, 3]
>>> z.append(5)
>>> print z
[1, 2, 3, 5]
>>> print z.pop()
5
>>> print z
[1, 2, 3]
>>>
In all truthfullness though, the book does suck... I like "The Quick Python Book" much better. And the html manual kicks ass... and there's always doc strings!:
>>> dir(z)
['append', 'count', 'extend', 'index', 'insert', 'pop', 'remove', 'reverse', 'so
rt']
>>> print z.append.__doc__
L.append(object) -- append object to end
>>>
Let me add to the list a 3,000 line package written in Python by yours truly that wraps around Microsoft Visual SourceSafe so that VSS can be used by Unix clients (python CGI talking to a python client script).
If anybody's interested I can put the source up for everybody to see/use (no docs though:-)...
I know I will be flamed to death, but I think the Unix/Linux community has to take off a couple of blindfolds: I like Unix and I want it to stay competitive.
With the exception of free programming tools, I think Windows has the edge on Unix on the rest as well:
* Scripting and text tools? windows scripting host exposes to any WSH-capable language (including Python and Perl) the entire system including components. Unix doesn't (technically OSX does and KDE is trying). Python, Perl, awk, sed, sort, head/tail, uniq, cut are all available on windows and work just as well there as they do on unix.
* Powerful and logical system management functions? It's true that Unix let's you customize a server to your heart's content, but I for one prefer Event Log over/var, Administrative Tools over/etc and Services Control panel over rc.d. And *anything* over linuxconf. Yes, the Windows *implementation* may leave a few things to be desired (fewer and fewer with every iteration of NT) but the design is sound. Unix may be powerful but it's far from logical.
Before the inevitable flames and downmods start, let me just say that I started using Unix before I touched DOS, never mind Windows. My hands type vi commands in Word to this day. I am at home in/etc. But the new generations of coders (never mind users) deserve something better than/etc, something cleaner than/var. Microsoft's answer may not be perfect, but at least MS (and Apple, thank god for Apple...) are trying. The Linux crowd is grabbing its security blanket and claims superiority even on areas that our favorite OS is clearly losing ground.
Absolutely true... but don't you think it's strange (or at least, extremely unprofessional) for a news website that covers PC hardware not to disclose anywhere that is owned, even indirectly by VA Linux? And even if we cannot get that fig leaf of professional journalism, what about a simple disclosure on blatantly negative posts about VA Linux competitors? Something like "Dell laptops break all the time, but I should tell you that I am an employee of a direct Dell competitor"?
People rag on MSNBC for their Microsoft coverage, but every single MSNBC article I've read on Microsoft properly discloses their part-ownership by MS --this despite that the name of the site is a compound of "Microsoft".
... I've owned and administered dozens of Dells. I've had few if any problems, and always, always Dell has provided excellent support --and more than half the time they did't need to: support.dell.com absolutely kicks ass.
But interestingly enough, I am typing this on a broken Dell laptop --ironic isn't it? This machine is completely hosed, it will BSOD if you move it an inch (external keyboards rule).
Anyway, it's my first truly broken Dell machine --ever. A corporate machine, purchased in Minneapolis for our company office in Atlanta. I am sitting right now in an apartment in Thessaloniki, Greece, 7,000 miles away from this machine's "home". I hang up the phone with US Dell Support an hour ago (collect). Dell has promised me that they will have a technician *on site* with a new motherboard *tomorrow morning*.
I will be sure to post Dell's performance here tomorrow. In the mean time, CmdrT., you may want to go tell VA that they have a long way to go to compete with these guys...
If you have a bad programmer on staff, then that's not your methodology's problem. You have HR and receuiting to fix first. Bad programmers are *never* good for the product, and they should never have been hired or kept on payroll in the first place.
OTOH, if you have *inexperienced*, but good programmers, having them tag-team with a more seasoned guy is gonna do them both a world of good --the fresh guy will learn, the older will have a sanity check and an alternative idea/design source.
Hmm... you're saying that Windows is easy to learn while Unix *can* be easy to use, if you put any effort into it. On the surface, I agree; but have you put that same effort into making *Windows* easy to use?
Beneath this IE window that I am typing this on, is a zsh window, running vim on NT 4SP5, inside a multi-dimensional DB that works on 4 unices and NT. This same machine is running Python (which can be hooked up to the Windows Scripting Host and take over the entire system) and Apache+PHP+MySQL. With a little bit of effort, all these Unix-toys play fine on my NT laptop and let me use MS Word, MS Visual Studio and all my wonderful Unix utilities, so I can then deploy to a Linux/Unix server.
I am wondering whether you'd be as productive on a well-setup windows machine (NT or 2K of course, nothing less) as on a well-setup unix machine, if only you put the same amount of effort into it...
I am not gonna argue that Python has more features or tools than Perl. God no... and Python IS sorely missing a CPAN-like archive (no, the Vaults won't do).
The main difference (besides subjective likes/dislikes, of course) between the two, is that Python is a descendant of general-purpose languages (albeit, mostly academic ones), while Perl is a descendant of specialized languages (shell scripting, AWK).
As a result Python tends to be easier for begginers to understand. That's not a bad thing, and it's not trivial either...
I am not familiar with Inline::, but... AFAIK, there is "perlpy", a Python module for hooking up to Perl. Jython pretty much is Python in Java, so you can subclass/extend/whatever Java from Python and vice versa. ActiveState's win32com extensions to Python allow full win32/MFC scripting from Python. Tcl is definitily hookable, as there is Python/TK which basically uses Tcl in the middle. I've seen MATLAB modules as well.
For compiled languages, anything that's hookable to C, it's easily hookable to Python. SWIG (swig.org) is of course most people's generator of choice (it does Perl as well, to be fair) but there is also a C++ API (CXX), several Fortran APIs and I dunno what else...
Yeah, I used to make fun of that too. I'll tell you a little (true) anecdote: I first heard of Python here on/. and its reliance on whitespace for code structure. I laughed and thought that was *such* a stupid idea.
I found it so funny in fact, that I went back to a couple of colleagues and started using Python as the punchline to an in-house joke: you see at the time we were looking for an embeddable scripting language. Python became a threat: "you'd better not do that, or I am gonna embed Python in the server".
Then, I started running into Python on the net, first because of Zope (of course) then on other cool little projects. I started to get curious, and downloaded the language and ActiveState's win32 extensions. I picked a small in-house project to test it on and I was pleasantly surprised: I went from making fun of it to piping serialized Python objects over HTTP (from NT to Unix and back no less) in --literally-- 3 days.
I dunno what your measure of a good language is, but that ease of use and versatility sold me. And, BTW, Python is now my company's embedded language of choice.
I have respect for Perl (hell, I have respect for any general-purpose language than can beat egrep in text searches), but Python is my weapon of choice.
What people are missing in this forum is that Python is probably the most extensible language out there: there are at least 4 different interpreter implementations for Python (and I don't mean OSes): there's C-Python, there's Jython (in Java), there is Stackless Python and there will be a Python.NET. That's versatile guys, much more so than any other 4GL language out there.
Also, Python is hacker-friendly: armed with a couple of tools and a C compiler anybody can embed the interpreter in their own app or extend Python with existing C, C++, Fortran, Java, or even Perl code. Trust me, it's much easier than you think.
Python is easier for begginers to pick up: if you have a diverse group of people with different skills, you can use Python as a lingua franca. No reason to explain the legacy behind $_ or other such awkiness:-)
Most importantly though, a choice of language is a personal one: I liken Python code to a mathematical proof: it's clean, it's elegant, and if it's written by someone else a reader can easily pick up its deficiencies. Perl tends to be more like poetry: it can be beautiful (like that great DeCSS hack) but its beauty is subjective, and much like poetry a lot of people may never 'get it'.
At any rate, if you are a Perlista and you're here flaming away because of the whitespace thing, go to python.org and try the language out. My bet is that you will be happy to have done so.
Well, helicopters do have wings: they just don't have *fixed* wings --the technical term is "rotor wing aircraft". And yes, helicopters can survive a complete power failure --go on google and look up "autorotation" or "autogyro", you will find out that a helicopter rotor is aerodynamically equivalent to a parachute of the same diameter while in autorotation.
Alright, the DC-X had redundancy built-in, I won't argue with that. But OTOH, no Air Force man would ever accept a spacecraft that *needed power* to stay up in the air... Commercial airplanes don't just have more than one engine, they also have *wings* to glide down to safety (well, kinda) in case of total power failure.
Now, I know originally the X-33 was supposed to be unmanned, but we all know that that was going to change sooner or later, no? Selling to the military (incl. NASA) means catering to the people that will fly/operate your technology, not just its niftiness.
Also, you're forgetting who the competitors were: a near-bankrupt McDonnel Douglas (soon to be picked up by Boeing), a down-and-out Rockwell (ditto) and Lockheed-Martin Skunk Works, the Air Force's own private development lab. Who do you think the military would trust more?
And if the DC-X was so cheap, how come hasn't Boeing picked it up and used it for their own commercial purposed instead of SeaLaunch?
I am no LM apologist, and I am genuinely sorry that all this money was wasted, but technology, tests and experience are never lost and will be used again (witness, e.g. the Boeing 747). Besides, I always thought Rockwell's proposal made the most sense...
I am tired of all the DC-X supporters here: the DC-X was an unbelievably cool idea that was executed well, but had one major flaw: no failsafe, no possibility of recovery in case of failure (parachutes don't work if you're close to the ground) which was demonstrated by the loss of the DC-Y.
Now, the X-33 (I forget LM's moniker pre-approval) could glide back into earth, had craploads of power to get to orbit, and if successful, the technologies that would have been developed around it, would have revolutionized space travel (the aerospike engine would be enough).
The curse of the X-33 was those damn cryogenic tanks and that old foe of aero engineers: center of gravity. The X-33 is basically a triangle, with a CG at about 2/3 of the way back. Now, if those cryo tanks need to work, they need to be big and strong. And where can you fit big, heavy tanks? in the back of the plane of course, which will cause the CG to move even further back, say 70-75% of the fuselage length. That's, for all intents and purposes, unflyable.
However, the X-33 did develop some kick-ass new thermal tiles, it proved the concept of the aerospike engine and it will still give us great technology for the next generation of spacecraft. What was basically disproven (and it was its demise) was lifting-body spacecraft (that CG thing again).
My guess: Rockwell's entry to the old X-33 competition, which was basically an updated Space Shuttle, would have been the prudent, conservative choice. If that idea is combined with what NASA can salvage from the X-33 technologies (aerospike, monocoque design, thermal tiles) the 3rd generation (in effect) shuttle will simply kick ass.
Well, it *may* mean that the people reading the article are not the ones coming back to the discussion thread. Have you noticed the comment counts lately? the user ID #s? how long have those been stuck at between 350-400k?
I am not trying to troll here, I am just pointing out something I've noticed...
Ramjets may be; scramjets I doubt, as there is no self-sustaining, thrust-producing scramjet in operations, AFAIK. Little problem with trying to combust air while it's travelling higher than the speed of sound (and thus pressure waves, and thus flames) of the medium combusting.
I disagree. Say you're a chief syasdmin, a COO, whatever, and you're using Win2K and Office 2K. Here comes MS selling Office 2002 for $X dollars and some other company (Corel, Ximian, whomever) selling another OS+Office suite package for $X/2. Hell, make it $0.
Do you think, honestly, that $X is what influences the final decision? No, the deciding factor is $Y, where Y>>X, and Y is equal to the costs associated with the switch: training support staff, training actual users and most importantly lost time and productivity with the new interface. The reason that MS still has a monopoly is that, a) noone has come up with a competitive product that is so much better to overcome $Y+X, and b) noone has gone all the way to eliminate $Y+X. I.e. we need OpenOffice to feel, work and integrate like MS Office and be either cheaper or better. Can Sun or GNU pull it off? I am sorry, but I don't think so --although I hope they do.
Well, the OS was lacking but the apps kicked ass. I remember when WP and 1-2-3 were a near-monopoly and the pains that MS had to go through to get Windows apps on people's desktops. Anybody remember Windows Lite (or whatever it was called) that was shipped with Excel just so people didn't have to run Windows? remember that WP keystrokes (and macros if memory serves) could run in Word? Those were not trivial features and MS did its best to put them in there so that people could switch over. Of course they're guarding their formats now, they know where the alternative leads:-)...
And as bad as Windows seems at times, it has always been backwardly compatible with MS products. That is also not a trivial feature; and if you take into account the multitude of hardware that MS OSes had to be tested against, maybe you would reconsider the arguments about quality as well.
I am no MS apologist, but/.ers seem to forget sometimes all the things that MS has done *right* (Excel, Word, Outlook, never mind the VBS virii) and remember all the things they've done wrong: if you underestimate your opponent they are bound to trounce all over you...
Well, this is purely subjective; I've been using a laptop as my main PC for >2 yrs now. And yes, I am a programmer and yes I spend >>8 hrs in front of a PC. The reason? I spend >>8 hrs in front of a PC: which means, I would like to be in control of my environment during that time, not the PC. I can work on my laptop at work, at home, on the road in an airplane, out in the balcony in this awesome weather we've been having, on my couch, etc, etc.
:-)...
Yes, laptops are more cramped (I have a MS Natural Keyboard hooked up to mine right now), but they are not necessarily slower than a desktop if they're beefy enough (RAM is important as the minute they hit a slow-ass 2.5" HD they slow down a lot) and an LCD screen is easier on the eyes for long periods of time, than even a kick ass CRT.
However, you're right, I too would like a VGA-in port. I have a coupla small boxes doing server work (NAT, etc) and having those ugly old CRTs around cramps my style
No, you got it wrong. Shipping is expensive but it's not necessarily more expensive to ship, say a book, from the publisher's factory to say B&N's distribution center to a B&N store than to ship it from the factory to an Amazon warehouse to the customer's doorstep. You would think the first route is cheaper (and it is), but not necessarily so...
What you are missing is two somethings called inventory and opportunity costs. When Barnes & Noble buys X number of books, hoping to sell, say 0.1X and planning to return 0.9X, it amortizes the logistic costs of returning 0.9X books into the profit margins of the 0.1X that it will sell (actual percentages are not as lop-sided but not too far off). Amazon on the other hand may not have to; so in the end, they could sell cheaper and ship directly...
The problem with the brick model is that B&N ties up a lot of cash up front to buy X books. Which means it's losing potential return from these monies that it could have invested elsewhere (the stock market, for instance, ha-ha; in reality better-selling stock, Harry Potter books for example). The first cost is the inventory cost. The lost profits from investing elsewhere is the opportunity cost.
Now, the Dell model of doing business is zero (actually *negative*) inventory cost: the customer has *pre-paid* his computer's components when they enter Dell's factories for assembly. That extra cash (billions of $$$ worth) Dell can use to agressively invest, expand, do whatever on earth it wants. More importantly, near-zero inventory means that Dell can change model lines on a dime. It's an agressive, ultra-efficient PC-making jugernaut.
Amazon on the other hand, cannot use the Dell model and still try to stock every book in existence. Doing so means that it's tying up cash (see above) and warehouse space for low-selling items. So, Amazon has to try and do what retailers do already: aggressively manage its supply chain for that top-10% of items that bring in the majority of the profits. Not try to be the freaking Library of Congress via 1-Click (btw, I am a loyal Amazon customer and I love their service; it just doesn't make any logistical sense).
Yeah, it's a tough problem; Supply chain optimization pushes modern computing hardware and software to its limits, and there's still a long way to go. Oh, did I mention my company is hiring? I need that referrer cash, so drop me a line if you're interested (Atlanta; very, very good C++, Java required).
Man... I love writing code in Python... it is fun as hell (OTOH, I also write awk, ksh, a coupla obscure SPLs you never heard of, so it's probably a bad comparison :-). And the truth is, you can be "dirty" in Python: do things the quick and easy way, instead of the proper OOP way. But, python allows you to quickly read even through bad code. And its ability to be dirty allows you to refactor such bad code easily.
Always, always, good code comes from good coders. A good language though, a) doesn't throw away the key of what the code does *cough*Perl*cough*, and b) allows you still enough flexibility to fix code, hack things together fast, etc *cough*Java*cough*.
Don't expect all of Perl's bells and whistles in Python: Guido doesn't want to pollute the language with equivalent ways of doing things, which makes perfect sense to me: helps readability, and forces everybody to strive towards increasing performance and features in the same 'niche' of code. But there's also *plenty* of power in the language and there is a very big toolset to work from...
In all truthfullness, you shouldn't: Java is faster than Python, and servlets kick ass.
:-)...
But say you wanted to be able to extend your servlet code, poke at live servlets, or get a lot of 'dirty' information out quickly (quickly as in development time). You can go to jython.org and grab a fully compliant Python interpreter implemented in Java. Presto, you got yourself a 4GL over your Java code. You can go google for JPE, a Java-Python bridge and go load Python extensions in C/C++ (much easier, IMHO than JNI) and talk to Python from Java and vice versa. Both Jython and JPE allow you to extend Python from Java and vice versa. That kicks ass...
Java has its place (that layer of apps just above C/C++) and so does Python (the layer on top of Java). The really great thing is that you won't have to switch mindsets. Python is clean, consistent, and really, really easy to write (much more so than Java, again IMHO).
Again, IMHO, I'd much rather prototype code in Python, work on the design, see what my design is missing, where I have to plug holes, and I can do so really quickly and easily (Python allows you to be more dirty than Java; multiple inheritance, writeable namespaces, exec(), etc...) and then I can profile the code (profiler comes with the std library) and extend the performance-bound parts in C/C++, again very easily. NumPy for example includes all of LINPACK: you get really great C/Fortran speed in numerical functions, but you get to use a RAD language.
Try it, you'll like it. Damn, that should be the Python slogan
Hmmm... Stack in Python... really hard... mind boggles:
Python 2.0 (#8, Oct 16 2000, 17:27:58) [MSC 32 bit (Intel)] on win32
Type "copyright", "credits" or "license" for more information.
>>> z = [1, 2, 3]
>>> z.append(5)
>>> print z
[1, 2, 3, 5]
>>> print z.pop()
5
>>> print z
[1, 2, 3]
>>>
In all truthfullness though, the book does suck... I like "The Quick Python Book" much better. And the html manual kicks ass... and there's always doc strings!:
>>> dir(z)
['append', 'count', 'extend', 'index', 'insert', 'pop', 'remove', 'reverse', 'so
rt']
>>> print z.append.__doc__
L.append(object) -- append object to end
>>>
Let me add to the list a 3,000 line package written in Python by yours truly that wraps around Microsoft Visual SourceSafe so that VSS can be used by Unix clients (python CGI talking to a python client script).
:-)...
If anybody's interested I can put the source up for everybody to see/use (no docs though
I know I will be flamed to death, but I think the Unix/Linux community has to take off a couple of blindfolds: I like Unix and I want it to stay competitive.
/var, Administrative Tools over /etc and Services Control panel over rc.d. And *anything* over linuxconf. Yes, the Windows *implementation* may leave a few things to be desired (fewer and fewer with every iteration of NT) but the design is sound. Unix may be powerful but it's far from logical.
/etc. But the new generations of coders (never mind users) deserve something better than /etc, something cleaner than /var. Microsoft's answer may not be perfect, but at least MS (and Apple, thank god for Apple...) are trying. The Linux crowd is grabbing its security blanket and claims superiority even on areas that our favorite OS is clearly losing ground.
With the exception of free programming tools, I think Windows has the edge on Unix on the rest as well:
* Scripting and text tools? windows scripting host exposes to any WSH-capable language (including Python and Perl) the entire system including components. Unix doesn't (technically OSX does and KDE is trying). Python, Perl, awk, sed, sort, head/tail, uniq, cut are all available on windows and work just as well there as they do on unix.
* Powerful and logical system management functions? It's true that Unix let's you customize a server to your heart's content, but I for one prefer Event Log over
Before the inevitable flames and downmods start, let me just say that I started using Unix before I touched DOS, never mind Windows. My hands type vi commands in Word to this day. I am at home in
I asked the same question on K5, but got no takers: has anybody played with ZODB outside of Zope? insights/impressions?
Absolutely true... but don't you think it's strange (or at least, extremely unprofessional) for a news website that covers PC hardware not to disclose anywhere that is owned, even indirectly by VA Linux? And even if we cannot get that fig leaf of professional journalism, what about a simple disclosure on blatantly negative posts about VA Linux competitors? Something like "Dell laptops break all the time, but I should tell you that I am an employee of a direct Dell competitor"?
People rag on MSNBC for their Microsoft coverage, but every single MSNBC article I've read on Microsoft properly discloses their part-ownership by MS --this despite that the name of the site is a compound of "Microsoft".
... I've owned and administered dozens of Dells. I've had few if any problems, and always, always Dell has provided excellent support --and more than half the time they did't need to: support.dell.com absolutely kicks ass.
But interestingly enough, I am typing this on a broken Dell laptop --ironic isn't it? This machine is completely hosed, it will BSOD if you move it an inch (external keyboards rule).
Anyway, it's my first truly broken Dell machine --ever. A corporate machine, purchased in Minneapolis for our company office in Atlanta. I am sitting right now in an apartment in Thessaloniki, Greece, 7,000 miles away from this machine's "home". I hang up the phone with US Dell Support an hour ago (collect). Dell has promised me that they will have a technician *on site* with a new motherboard *tomorrow morning*.
I will be sure to post Dell's performance here tomorrow. In the mean time, CmdrT., you may want to go tell VA that they have a long way to go to compete with these guys...
Hmmm... I just looked into LiveJournal. Yes, it looks well made, but I cannot find the source to the *server* anywhere... pointers?
If you have a bad programmer on staff, then that's not your methodology's problem. You have HR and receuiting to fix first. Bad programmers are *never* good for the product, and they should never have been hired or kept on payroll in the first place.
OTOH, if you have *inexperienced*, but good programmers, having them tag-team with a more seasoned guy is gonna do them both a world of good --the fresh guy will learn, the older will have a sanity check and an alternative idea/design source.
Hmm... you're saying that Windows is easy to learn while Unix *can* be easy to use, if you put any effort into it. On the surface, I agree; but have you put that same effort into making *Windows* easy to use?
Beneath this IE window that I am typing this on, is a zsh window, running vim on NT 4SP5, inside a multi-dimensional DB that works on 4 unices and NT. This same machine is running Python (which can be hooked up to the Windows Scripting Host and take over the entire system) and Apache+PHP+MySQL. With a little bit of effort, all these Unix-toys play fine on my NT laptop and let me use MS Word, MS Visual Studio and all my wonderful Unix utilities, so I can then deploy to a Linux/Unix server.
I am wondering whether you'd be as productive on a well-setup windows machine (NT or 2K of course, nothing less) as on a well-setup unix machine, if only you put the same amount of effort into it...
I am not gonna argue that Python has more features or tools than Perl. God no... and Python IS sorely missing a CPAN-like archive (no, the Vaults won't do).
The main difference (besides subjective likes/dislikes, of course) between the two, is that Python is a descendant of general-purpose languages (albeit, mostly academic ones), while Perl is a descendant of specialized languages (shell scripting, AWK).
As a result Python tends to be easier for begginers to understand. That's not a bad thing, and it's not trivial either...
I am not familiar with Inline::, but... AFAIK, there is "perlpy", a Python module for hooking up to Perl. Jython pretty much is Python in Java, so you can subclass/extend/whatever Java from Python and vice versa. ActiveState's win32com extensions to Python allow full win32/MFC scripting from Python. Tcl is definitily hookable, as there is Python/TK which basically uses Tcl in the middle. I've seen MATLAB modules as well.
For compiled languages, anything that's hookable to C, it's easily hookable to Python. SWIG (swig.org) is of course most people's generator of choice (it does Perl as well, to be fair) but there is also a C++ API (CXX), several Fortran APIs and I dunno what else...
Yeah, I used to make fun of that too. I'll tell you a little (true) anecdote: I first heard of Python here on /. and its reliance on whitespace for code structure. I laughed and thought that was *such* a stupid idea.
I found it so funny in fact, that I went back to a couple of colleagues and started using Python as the punchline to an in-house joke: you see at the time we were looking for an embeddable scripting language. Python became a threat: "you'd better not do that, or I am gonna embed Python in the server".
Then, I started running into Python on the net, first because of Zope (of course) then on other cool little projects. I started to get curious, and downloaded the language and ActiveState's win32 extensions. I picked a small in-house project to test it on and I was pleasantly surprised: I went from making fun of it to piping serialized Python objects over HTTP (from NT to Unix and back no less) in --literally-- 3 days.
I dunno what your measure of a good language is, but that ease of use and versatility sold me. And, BTW, Python is now my company's embedded language of choice.
...but it's not there yet.
:-)
I have respect for Perl (hell, I have respect for any general-purpose language than can beat egrep in text searches), but Python is my weapon of choice.
What people are missing in this forum is that Python is probably the most extensible language out there: there are at least 4 different interpreter implementations for Python (and I don't mean OSes): there's C-Python, there's Jython (in Java), there is Stackless Python and there will be a Python.NET. That's versatile guys, much more so than any other 4GL language out there.
Also, Python is hacker-friendly: armed with a couple of tools and a C compiler anybody can embed the interpreter in their own app or extend Python with existing C, C++, Fortran, Java, or even Perl code. Trust me, it's much easier than you think.
Python is easier for begginers to pick up: if you have a diverse group of people with different skills, you can use Python as a lingua franca. No reason to explain the legacy behind $_ or other such awkiness
Most importantly though, a choice of language is a personal one: I liken Python code to a mathematical proof: it's clean, it's elegant, and if it's written by someone else a reader can easily pick up its deficiencies. Perl tends to be more like poetry: it can be beautiful (like that great DeCSS hack) but its beauty is subjective, and much like poetry a lot of people may never 'get it'.
At any rate, if you are a Perlista and you're here flaming away because of the whitespace thing, go to python.org and try the language out. My bet is that you will be happy to have done so.
Well, helicopters do have wings: they just don't have *fixed* wings --the technical term is "rotor wing aircraft". And yes, helicopters can survive a complete power failure --go on google and look up "autorotation" or "autogyro", you will find out that a helicopter rotor is aerodynamically equivalent to a parachute of the same diameter while in autorotation.
Alright, the DC-X had redundancy built-in, I won't argue with that. But OTOH, no Air Force man would ever accept a spacecraft that *needed power* to stay up in the air... Commercial airplanes don't just have more than one engine, they also have *wings* to glide down to safety (well, kinda) in case of total power failure.
Now, I know originally the X-33 was supposed to be unmanned, but we all know that that was going to change sooner or later, no? Selling to the military (incl. NASA) means catering to the people that will fly/operate your technology, not just its niftiness.
Also, you're forgetting who the competitors were: a near-bankrupt McDonnel Douglas (soon to be picked up by Boeing), a down-and-out Rockwell (ditto) and Lockheed-Martin Skunk Works, the Air Force's own private development lab. Who do you think the military would trust more?
And if the DC-X was so cheap, how come hasn't Boeing picked it up and used it for their own commercial purposed instead of SeaLaunch?
I am no LM apologist, and I am genuinely sorry that all this money was wasted, but technology, tests and experience are never lost and will be used again (witness, e.g. the Boeing 747). Besides, I always thought Rockwell's proposal made the most sense...
I am tired of all the DC-X supporters here: the DC-X was an unbelievably cool idea that was executed well, but had one major flaw: no failsafe, no possibility of recovery in case of failure (parachutes don't work if you're close to the ground) which was demonstrated by the loss of the DC-Y.
Now, the X-33 (I forget LM's moniker pre-approval) could glide back into earth, had craploads of power to get to orbit, and if successful, the technologies that would have been developed around it, would have revolutionized space travel (the aerospike engine would be enough).
The curse of the X-33 was those damn cryogenic tanks and that old foe of aero engineers: center of gravity. The X-33 is basically a triangle, with a CG at about 2/3 of the way back. Now, if those cryo tanks need to work, they need to be big and strong. And where can you fit big, heavy tanks? in the back of the plane of course, which will cause the CG to move even further back, say 70-75% of the fuselage length. That's, for all intents and purposes, unflyable.
However, the X-33 did develop some kick-ass new thermal tiles, it proved the concept of the aerospike engine and it will still give us great technology for the next generation of spacecraft. What was basically disproven (and it was its demise) was lifting-body spacecraft (that CG thing again).
My guess: Rockwell's entry to the old X-33 competition, which was basically an updated Space Shuttle, would have been the prudent, conservative choice. If that idea is combined with what NASA can salvage from the X-33 technologies (aerospike, monocoque design, thermal tiles) the 3rd generation (in effect) shuttle will simply kick ass.
Well, it *may* mean that the people reading the article are not the ones coming back to the discussion thread. Have you noticed the comment counts lately? the user ID #s? how long have those been stuck at between 350-400k?
I am not trying to troll here, I am just pointing out something I've noticed...
Ramjets may be; scramjets I doubt, as there is no self-sustaining, thrust-producing scramjet in operations, AFAIK. Little problem with trying to combust air while it's travelling higher than the speed of sound (and thus pressure waves, and thus flames) of the medium combusting.
I am an idiot: %s/Y+X/Y-X/g
I disagree. Say you're a chief syasdmin, a COO, whatever, and you're using Win2K and Office 2K. Here comes MS selling Office 2002 for $X dollars and some other company (Corel, Ximian, whomever) selling another OS+Office suite package for $X/2. Hell, make it $0.
Do you think, honestly, that $X is what influences the final decision? No, the deciding factor is $Y, where Y>>X, and Y is equal to the costs associated with the switch: training support staff, training actual users and most importantly lost time and productivity with the new interface. The reason that MS still has a monopoly is that, a) noone has come up with a competitive product that is so much better to overcome $Y+X, and b) noone has gone all the way to eliminate $Y+X. I.e. we need OpenOffice to feel, work and integrate like MS Office and be either cheaper or better. Can Sun or GNU pull it off? I am sorry, but I don't think so --although I hope they do.
Well, the OS was lacking but the apps kicked ass. I remember when WP and 1-2-3 were a near-monopoly and the pains that MS had to go through to get Windows apps on people's desktops. Anybody remember Windows Lite (or whatever it was called) that was shipped with Excel just so people didn't have to run Windows? remember that WP keystrokes (and macros if memory serves) could run in Word? Those were not trivial features and MS did its best to put them in there so that people could switch over. Of course they're guarding their formats now, they know where the alternative leads :-)...
/.ers seem to forget sometimes all the things that MS has done *right* (Excel, Word, Outlook, never mind the VBS virii) and remember all the things they've done wrong: if you underestimate your opponent they are bound to trounce all over you...
And as bad as Windows seems at times, it has always been backwardly compatible with MS products. That is also not a trivial feature; and if you take into account the multitude of hardware that MS OSes had to be tested against, maybe you would reconsider the arguments about quality as well.
I am no MS apologist, but