My website is not linux-focused, but it also aggregates news from tech news sites --and also filters them, ranks them (based on user opinion) and links to the discussion on/. or K5 if it was linked from there: memigo
Well, there are obviously fewer things that untrusted input can break in an interpreted language (no buffer overflows for one).
I don't know if that's what you have in mind, but at least Python's exec() and eval() allow for namespace definition (i.e. only let the exec/eval'ed code to have access to a portion of the variable namespace.
Re:Perl's had it's day - It's become like COBOL
on
Apocalypse 5 Released
·
· Score: 2
I totally respect Perl's text-parsing abilities. And it's certainly more prevalent than python (and python's 're' regex module pretty much copies Perl5 regexes). And it's faster than python in the majority of cases.
However, 'text parsing' is a limited domain; in that domain awk is almost as capable as perl (and, often, faster). You won't see any awk-powered websites though. The reason, I believe, is that dynamic websites are not in the 'text parsing' domain, even if at at the user-end of the system you're just pushing html.
There's data management, permissions/authorization, delegation, flexibility, and a myriad other issues to think about that pretty much move dynamic websites to a GUI-app domain more than a report-creation domain. Think of/., say as a GUI, where HTML is the GUI toolkit, mod_perl is the underlying OS(in effect) and Slashcode is the application (with MySQL as the storage layer).
That's a much closer analogy to the web app domain than generating old-fashioned reports out of a SQL backend on a mainframe --where arguably perl excels at.
I am not saying perl is a bad language or that you can't build good applications with it. You certainly can, and people do. But, for some problems, and certainly for web apps, there are better tools out there, and I believe python is one of them.
Re:Perl's had it's day - It's become like COBOL
on
Apocalypse 5 Released
·
· Score: 2
I certainly agree. Perl doesn't 'feel' right, it feels/looks contorted somehow, a square peg trying to fit into a round hole and all that --yes, I know awk and sed and ksh and I wouldn't want to program a big web app in any of them or a blend thereof.
I am a Python fan and I can readily admit to some Python weaknesses, but overall Python feels cleaner and predictable. For instance, Python already has changed regexes; but because they don't come built in to the main language syntax (as they shouldn't; not everything is about text), it was a painless transition for everybody involved. I am sure that if Perl6's regexes gain acceptance, there will soon be a new Python module to accommodate them.
Tab completion is most complete in Zsh (pun intended). Z has a lot of extremely useful options builtin, and if everything else fails, it's easy to write your own.
Well, I am a rocket scientist and I couldn't agree with you more.
The "two guys from Ohio" were way, way ahead of their time. They were among the first to do actual experiment-based airfoil testing. They developed light-weight internal combustion engines. Their biggest breakthrough was realizing the importance of control: they developed twistable wings (the ailerons were invented later) to maneuver the airplane. It's not like major military powers were not trying to do the same thing; it's just that the two bicycle shop owners persisted and had the insight and ingenuity to do this.
Space travel has a much lower threshold today than air flight did for the Wrights: we know how to get there, we know how to survive, we know how to spread the risks. The difference is cost: it will take more than two dedicated hobbyists to build a space vehicle. And it will take a market demand to amortize the costs and make space travel possible; I think that's a bigger obstacle than technology or cost.
As a Stanford grad, I have to disagree (HP grew out of Stanford and vice versa). Messrs Packard and Hewlett spent a very big chunk of their fortune on philanthropy, medical research, and education. They build a company that showed respect for its employees, that flourished on enterprise and innovation and that spurred the community that surrounded to flourish too. Never mind the fact that HP was the spark that ignited Silicon Valley.
Corporations should not, as a rule, be anthropomorphosized by mourning their passing or by promising unconditional loyalty. However, HP is (alas, was) one of the exceptions to that rule. HP is dead, long live HP...
I played with one in an Atlanta CompUSA just this past Saturday. It's very, very nice, but I will be waiting for the new XScale PPCs before I upgrade from my Vx...
Re:Um. Its trivial to make it work with PAL...
on
TiVo Series 2 Review
·
· Score: 2
I was worried about the same thing and found the hack you refer to. However, what I didn't find, and it's a show-stopper for me, it's a way to pipe your own schedules into TiVo. I would be glad to pay TiVo money for the service, but I want to use it in a country they don't cover, so I'd have to hack my own. Is it doable? I am guessing so, from your Australia comment, but how?
Let me make the above clearer: Say you have a document, with a root tag "collection", containing several "book" tags (I am too lazy to insert angle brackets here). XML Objectify will allow you for example to create an XO_Book class that will be automatically instantiated for each "book" tag in your document. It will also instantiate an XO_Collection class that you may also overload (or not).
For example, say that you want to have a method, file(), attached to each book. You can create that method (in Python), attach it to the XO_Book class and then run your XML file through XML Objectify. You will get back an object containing the root of the XML file and objects for each tag encountered within. If there are multiple tags, you get a magical iterator. So, my example above will look like this:
collection = xml_objectify.xml_objectify(myxmlfile) for book in collection.book:
book.file()
Procedural and OOP power, while still talking to XML. Combine that with a good template engine (Cheetah for Python is very nice) and you will hit the ground running really fast w/o XSLT.
I co-wrote a small XML->Python de-serializer. Go to gnosis.cx and look around for "XML Tools". XML Objectify does exactly what you're looking for: grabs an XML file and gives you a clean object that you can loop through, attach methods to, etc, at SAX speeds. I don't know if it's doable in Perl, but probably if you mix enough $@->$_ in there it could be done:-) (couldn't resist...)
Joel Spolsky makes good points and his articles are usually excellent reading, regardless if you agree with him or not --I usually do. However, I think he over-generalizes his conclusions based on his own experience --selling consumer-oriented, "shrink-wrap" software. He leaves the entire enterprise software world out of his viewpoint and some of his conclusions don't make sense in that sphere.
For example, I tend to agree that "software doesn't rust". But that holds if your customer is Joe Q Public; it doesn't (usually) hold for enterprises. E.g. his Net Present Value calculation in the article doesn't take into account opportunity cost, i.e. the competitive advantage a company would gain if it upgraded their old F77 program into a faster one, with more mindshare (easier to lure/train IT staff) and more features that would increase productivity and lower costs.
Again, I do usually agree with Joel and read his essays religiously, but I wish he opened his worldview to the rest of the software industry.
There is a native Zsh port for win32 that works very nicely (case insensitivity, path translation, etc) and doesn't require Cygwin. Zsh itself is more powerful than tcsh and although it's a sh-like shell (in the family of ksh and bash) it has lots of c/tcsh-like feature to help ease the transition.
Version control a-la VMS anyone? the FS is a full RDBMS, it could potentially store transaction history so that you could have multi-level undo at the FS level (eat that, Veritas).
Separation of file content from metadata? Sync your word file to your PocketPC and that device only gets the data it "knows" about (a "consumer" which only understands certain "interfaces", if it helps to think of this that way).
Virtual directories? screw the strict hierarchical view of the world. Directories can finally be SQL queries! I mean they are now, but they only depend on the filename and path. Imagine a directory that literally is the result of the query "all files that were sent to this customer in the last 2 months". Seamless.
Network transparency. I posted this in another comment. This pushes the windows object orientation down to the FS. Dot-NET pushes it up to the network. RDBMS can already support redundancy and clustering. Take that concept to the NFS/distributed computing level.
This is a huge technological leap forward. We've been working on super-powerful DBs for years, but we were limited to a stupid tree when it came to our own personal data management. This is big.
Completely agreed. This extends the OO nature of Windows down to the FS level..NET extends it up to the network level. It's a huge play by MS and it's a huge step forward.
If only Windows Scripting Host gave you a more dead-easy way to script/tinker with the Windows objects...
How can the storage medium be in any way involved in DRM? If you can crack a DRM scheme based on an HD serial number, why cann't you do the same for a DB-based DRM?
Since I am in the market to replace my Vx, here's what I like about the Loox: SD and CF card slots (instead of just CF like HP, or just SD like Palm/Compaq or MemoryStick like Sony), jog dial (only Sony and Handspring), Color QVGA screen (only PocketPC), integrated Bluetooth (only Compaq).
However, the most serious spec is missing: size. I like the iPaq, but it's too big for carrying around everywhere. If this thing is close to the T- or N- series Clie in size, I'll be first in line to get one.
Buy an extension IDE ribbon. Usually, the pinout is reachable on the bottom of the HD (i.e. you can see where the plug is soldered onto the controller board. By looking at the controller board you can figure out which plug-pin is which lead on the board. Plug your extension cord to the HD. Cut the wires of the ribbon that you know don't work. Solder said cut pieces onto the board pins directly. Mount HDD. Remove all data ASAP. Throw away HDD.
I've done something pretty close in the past. The HDD is still mounted on a 486, still chugging along. Don't consider my past luck any sort of good omen for yours. You may fry the HDD, your controller and/or the motherboard.
Prosecute in what jurisdiction? enforce copyright in which country? Trust who? your customer contact? their admins? their late-night machine room operator who can reboot the co-located machine in single-user mode?
I've been wanting to use Python for applications that require guarding against malicious users --yes, in effect I am looking for Locked Source, flame away.
I am wondering if you can compile a python interpreter with an embedded public key; you could then encrypt your code with your private key and still be able to ship it to a co-lo or an untrusted client site.
However, I cannot see how this can be generalized without the public key being extractable from the interpreter executable itself or from the code itself in RAM... Thoughts?
I don't want to post this to every Zope story, but I feel your pain: try Webware for Python as an alternative to Zope. It's basically a servlet server (with some high-level APIs built-in) written in Python. Performance is good --although less than a good Java server to be honest-- and it's less restrictive than Zope (you can use a text editor or an IDE to develop code).
I have actually set up Beowulfs using Dell Poweredges 2 years ago. I don't know about now, but back then you got a 4CPU license of NT4 Server with each quad box. We had to format the RAIDs to get RH on them.
So, no, licensing is definitely *not* an issue. However, availability of software and mindshare among beowulf people is an issue, and that's where linux has the edge.
... but if you are a control freak (like myself), Zope can be too constraining. On the other hand, Webware for Python provides a clean, very OOPy, servlet server written entirely in Python. It's not necessarily better than Zope (Zope is by far more mature) but it does offer you more control over your app.
Slashdot Mirror
My website is not linux-focused, but it also aggregates news from tech news sites --and also filters them, ranks them (based on user opinion) and links to the discussion on /. or K5 if it was linked from there: memigo
Well, there are obviously fewer things that untrusted input can break in an interpreted language (no buffer overflows for one).
I don't know if that's what you have in mind, but at least Python's exec() and eval() allow for namespace definition (i.e. only let the exec/eval'ed code to have access to a portion of the variable namespace.
I totally respect Perl's text-parsing abilities. And it's certainly more prevalent than python (and python's 're' regex module pretty much copies Perl5 regexes). And it's faster than python in the majority of cases.
/., say as a GUI, where HTML is the GUI toolkit, mod_perl is the underlying OS(in effect) and Slashcode is the application (with MySQL as the storage layer).
However, 'text parsing' is a limited domain; in that domain awk is almost as capable as perl (and, often, faster). You won't see any awk-powered websites though. The reason, I believe, is that dynamic websites are not in the 'text parsing' domain, even if at at the user-end of the system you're just pushing html.
There's data management, permissions/authorization, delegation, flexibility, and a myriad other issues to think about that pretty much move dynamic websites to a GUI-app domain more than a report-creation domain. Think of
That's a much closer analogy to the web app domain than generating old-fashioned reports out of a SQL backend on a mainframe --where arguably perl excels at.
I am not saying perl is a bad language or that you can't build good applications with it. You certainly can, and people do. But, for some problems, and certainly for web apps, there are better tools out there, and I believe python is one of them.
I certainly agree. Perl doesn't 'feel' right, it feels/looks contorted somehow, a square peg trying to fit into a round hole and all that --yes, I know awk and sed and ksh and I wouldn't want to program a big web app in any of them or a blend thereof.
I am a Python fan and I can readily admit to some Python weaknesses, but overall Python feels cleaner and predictable. For instance, Python already has changed regexes; but because they don't come built in to the main language syntax (as they shouldn't; not everything is about text), it was a painless transition for everybody involved. I am sure that if Perl6's regexes gain acceptance, there will soon be a new Python module to accommodate them.
Tab completion is most complete in Zsh (pun intended). Z has a lot of extremely useful options builtin, and if everything else fails, it's easy to write your own.
Well, I am a rocket scientist and I couldn't agree with you more.
The "two guys from Ohio" were way, way ahead of their time. They were among the first to do actual experiment-based airfoil testing. They developed light-weight internal combustion engines. Their biggest breakthrough was realizing the importance of control: they developed twistable wings (the ailerons were invented later) to maneuver the airplane. It's not like major military powers were not trying to do the same thing; it's just that the two bicycle shop owners persisted and had the insight and ingenuity to do this.
Space travel has a much lower threshold today than air flight did for the Wrights: we know how to get there, we know how to survive, we know how to spread the risks. The difference is cost: it will take more than two dedicated hobbyists to build a space vehicle. And it will take a market demand to amortize the costs and make space travel possible; I think that's a bigger obstacle than technology or cost.
As a Stanford grad, I have to disagree (HP grew out of Stanford and vice versa). Messrs Packard and Hewlett spent a very big chunk of their fortune on philanthropy, medical research, and education. They build a company that showed respect for its employees, that flourished on enterprise and innovation and that spurred the community that surrounded to flourish too. Never mind the fact that HP was the spark that ignited Silicon Valley.
Corporations should not, as a rule, be anthropomorphosized by mourning their passing or by promising unconditional loyalty. However, HP is (alas, was) one of the exceptions to that rule. HP is dead, long live HP...
I played with one in an Atlanta CompUSA just this past Saturday. It's very, very nice, but I will be waiting for the new XScale PPCs before I upgrade from my Vx...
I was worried about the same thing and found the hack you refer to. However, what I didn't find, and it's a show-stopper for me, it's a way to pipe your own schedules into TiVo. I would be glad to pay TiVo money for the service, but I want to use it in a country they don't cover, so I'd have to hack my own. Is it doable? I am guessing so, from your Australia comment, but how?
Let me make the above clearer: Say you have a document, with a root tag "collection", containing several "book" tags (I am too lazy to insert angle brackets here). XML Objectify will allow you for example to create an XO_Book class that will be automatically instantiated for each "book" tag in your document. It will also instantiate an XO_Collection class that you may also overload (or not).
For example, say that you want to have a method, file(), attached to each book. You can create that method (in Python), attach it to the XO_Book class and then run your XML file through XML Objectify. You will get back an object containing the root of the XML file and objects for each tag encountered within. If there are multiple tags, you get a magical iterator. So, my example above will look like this:
collection = xml_objectify.xml_objectify(myxmlfile)
for book in collection.book:
book.file()
Procedural and OOP power, while still talking to XML. Combine that with a good template engine (Cheetah for Python is very nice) and you will hit the ground running really fast w/o XSLT.
I co-wrote a small XML->Python de-serializer. Go to gnosis.cx and look around for "XML Tools". XML Objectify does exactly what you're looking for: grabs an XML file and gives you a clean object that you can loop through, attach methods to, etc, at SAX speeds. I don't know if it's doable in Perl, but probably if you mix enough $@->$_ in there it could be done :-) (couldn't resist...)
I read the site a week ago. The end conclusion is that an MLM (Multi-Level Marketing) is behind all of this: Herbalife.
The other interesting part of the story is that just today, a group of VCs bought out Herbalife which floundered after its founder OD'ed.
Joel Spolsky makes good points and his articles are usually excellent reading, regardless if you agree with him or not --I usually do. However, I think he over-generalizes his conclusions based on his own experience --selling consumer-oriented, "shrink-wrap" software. He leaves the entire enterprise software world out of his viewpoint and some of his conclusions don't make sense in that sphere.
For example, I tend to agree that "software doesn't rust". But that holds if your customer is Joe Q Public; it doesn't (usually) hold for enterprises. E.g. his Net Present Value calculation in the article doesn't take into account opportunity cost, i.e. the competitive advantage a company would gain if it upgraded their old F77 program into a faster one, with more mindshare (easier to lure/train IT staff) and more features that would increase productivity and lower costs.
Again, I do usually agree with Joel and read his essays religiously, but I wish he opened his worldview to the rest of the software industry.
There is a native Zsh port for win32 that works very nicely (case insensitivity, path translation, etc) and doesn't require Cygwin. Zsh itself is more powerful than tcsh and although it's a sh-like shell (in the family of ksh and bash) it has lots of c/tcsh-like feature to help ease the transition.
Isn't it clear what they have in mind? Oracle. SAP. Baan.
Think about it.
Hmmm... A few thoughts that this enables:
Version control a-la VMS anyone? the FS is a full RDBMS, it could potentially store transaction history so that you could have multi-level undo at the FS level (eat that, Veritas).
Separation of file content from metadata? Sync your word file to your PocketPC and that device only gets the data it "knows" about (a "consumer" which only understands certain "interfaces", if it helps to think of this that way).
Virtual directories? screw the strict hierarchical view of the world. Directories can finally be SQL queries! I mean they are now, but they only depend on the filename and path. Imagine a directory that literally is the result of the query "all files that were sent to this customer in the last 2 months". Seamless.
Network transparency. I posted this in another comment. This pushes the windows object orientation down to the FS. Dot-NET pushes it up to the network. RDBMS can already support redundancy and clustering. Take that concept to the NFS/distributed computing level.
This is a huge technological leap forward. We've been working on super-powerful DBs for years, but we were limited to a stupid tree when it came to our own personal data management. This is big.
Completely agreed. This extends the OO nature of Windows down to the FS level. .NET extends it up to the network level. It's a huge play by MS and it's a huge step forward.
If only Windows Scripting Host gave you a more dead-easy way to script/tinker with the Windows objects...
How can the storage medium be in any way involved in DRM? If you can crack a DRM scheme based on an HD serial number, why cann't you do the same for a DB-based DRM?
Since I am in the market to replace my Vx, here's what I like about the Loox: SD and CF card slots (instead of just CF like HP, or just SD like Palm/Compaq or MemoryStick like Sony), jog dial (only Sony and Handspring), Color QVGA screen (only PocketPC), integrated Bluetooth (only Compaq).
However, the most serious spec is missing: size. I like the iPaq, but it's too big for carrying around everywhere. If this thing is close to the T- or N- series Clie in size, I'll be first in line to get one.
Buy an extension IDE ribbon. Usually, the pinout is reachable on the bottom of the HD (i.e. you can see where the plug is soldered onto the controller board. By looking at the controller board you can figure out which plug-pin is which lead on the board. Plug your extension cord to the HD. Cut the wires of the ribbon that you know don't work. Solder said cut pieces onto the board pins directly. Mount HDD. Remove all data ASAP. Throw away HDD.
I've done something pretty close in the past. The HDD is still mounted on a 486, still chugging along. Don't consider my past luck any sort of good omen for yours. You may fry the HDD, your controller and/or the motherboard.
Prosecute in what jurisdiction? enforce copyright in which country? Trust who? your customer contact? their admins? their late-night machine room operator who can reboot the co-located machine in single-user mode?
So, can you obfuscate an encrypted interpreter?
I've been wanting to use Python for applications that require guarding against malicious users --yes, in effect I am looking for Locked Source, flame away.
I am wondering if you can compile a python interpreter with an embedded public key; you could then encrypt your code with your private key and still be able to ship it to a co-lo or an untrusted client site.
However, I cannot see how this can be generalized without the public key being extractable from the interpreter executable itself or from the code itself in RAM... Thoughts?
I don't want to post this to every Zope story, but I feel your pain: try Webware for Python as an alternative to Zope. It's basically a servlet server (with some high-level APIs built-in) written in Python. Performance is good --although less than a good Java server to be honest-- and it's less restrictive than Zope (you can use a text editor or an IDE to develop code).
I have actually set up Beowulfs using Dell Poweredges 2 years ago. I don't know about now, but back then you got a 4CPU license of NT4 Server with each quad box. We had to format the RAIDs to get RH on them.
So, no, licensing is definitely *not* an issue. However, availability of software and mindshare among beowulf people is an issue, and that's where linux has the edge.
... but if you are a control freak (like myself), Zope can be too constraining. On the other hand, Webware for Python provides a clean, very OOPy, servlet server written entirely in Python. It's not necessarily better than Zope (Zope is by far more mature) but it does offer you more control over your app.