Re:Most mathematics is GIBBERISH.
on
Open Source Math
·
· Score: 1
I won't argue this assertion:
These hypocrites want tens of thousands of dollars of compiled code for free, and, beyond that, billions of dollars of source code for free - yet they won't post their LaTeX's or their PDF's for free [choosing instead to have Springer Verlag, Wiley, Elsevier, et al, demand $150+ per copy], they won't give away their journals for free, they won't open their libraries for free [demanding instead that you pony up $40,000 to $50,000 in tuition, fees, room, and board before you can get an ID card that will offer admittance to the library], they won't open up their student lectures for free [see ID card, as above], they won't open up their conferences for free [try sneaking into a conference lecture hall without an ID badge], etc etc etc.
I agree it is the 'pot calling the kettle black' when folks like this complain about for-profit companies not releasing source code. I also agree that people and companies can similarly demand compensation for their work with whatever limitations they demand. Caveat emptor.
That being said, the status quo does not address the problem of independent verification. Another solution (and the solution mentioned in the editorial) is to instead of depending upon proprietary software, mathematicians should support open source projects (and the editorial writer mentioned in his 'full disclosure' that he was involved in just such a project) that by definition provide the opportunity to review code when questions of validity arise. And they will arise in all cases - regardless of whether the code is proprietary or FOSS:
It is not necessarily the case that "free source code" always implies better, less error-prone code.
I agree completely with this statement, and said as much in my parent post. The difference is that with open source the community has the opportunity to validate the code when questions arise (I'll say it again) which is not the case with proprietary software.
1) Most published "mathematics" doesn't even qualify as false - rather, it's just gibberish, plain and simple. If a person with a sufficiently high IQ, a sufficiently meticulous personality, sufficient time on his hands, and sufficient sleep at night [leading to sufficent energy in the daytime] - if such a person were to examine the average published "mathematics" paper, then he would quickly come to realize that the words in the paper didn't even coalesce into logically well-formed statements.
I am assuming you meet all the self defined qualifications to make such a statement? While something may be esoteric to you doesn't qualify it as 'gibberish'. This statement makes quite a lot of assumptions with little facts to back it up.
2) Within the subset of published "mathematics" which isn't outright gibberish, most stated "results" are false: If a person with a sufficiently high IQ [and personality/time/sleep/etc] were to examine the average non-gibberish "mathematics" paper [after it had passed muster with Kurt Gödel & Alan Turing's gibberish-detecting filter, to ensure that it wasn't gibberish in the first place], then, pretty early on, he would come to realize that there were intractable errors in the paper, and he'd throw his hands up in despair and move on to some more productive use of his time.
Again, more assumptions without facts.
3) Within the tiny subset of all published "mathematics" papers which aren't gibberish, and which contain assertions which are actually true, and which contain "proofs" of those assertions which aren't riddled with intractable errors, it is still exceedingly unlikely that a dis-interested third party [with sufficiently high IQ and personality/time/sleep/etc] will ever come along and verify that the paper is correct in the first place.
Ditto.
Only a tiny, tiny fraction of all "results" in mathematics these days ever d
Re:I'm not the hypocrite here.
on
Open Source Math
·
· Score: 4, Insightful
The issue is not whether software companies should make their source code open - the real issue is should mathematicians accept proprietary applications as proof of theorums?
As pointed out in the editorial, software developers make mistakes, and this is true regardless of whether that developer is a proprietary software vendor, or a free/open source software project. There is one key difference however, the validity of any given proof can be determined independently when using free/open source code by the very nature of the product (availability of source code). There is no validation for proprietary software beyond the assurances of the company involved.
When mathematic theory becomes applied mathematics (such as the creation of buildings, bridges, aircraft, or thermonuclear devices), which proof would you prefer to hang your life upon - Microsoft's guarantee, or independent verification and peer review? This becomes ever more critical as we create more complex systems that can not be easily verified by hand, yet rushed into applied use by the expediency/efficiencies they deem to provide.
People have been using geothermal heat pumps for maintaining house temperature as a sustainable alternative to the traditional gas/electric air conditioner/furnace combination for years now (1 million installed base currently). A liquid is moved through pipes placed in the ground - in direct contact with earth or water - to remove the waste heat for cooling, and to absorb heat for warming.
While this approach may save money for the company, and is certainly a 'greener' approach than traditional data centers, there are other factors that make it a desirable solution:
1. Physical security. Getting into a mine is difficult - and generally accessible from one point - which can be controlled easier than an above ground structure.
2. EMP security. In the event of a nuclear war or similarevent that could produce significant EMP, an underground site is your best bet. If wired properly, I am sure Sun's Black Boxes also serve as nice Faraday cages as an added bonus. Aside from a direct hit on the mineshaft, your data will be secure.
3. Geographical dispersion. Another component of disaster recovery is maintaining copies of your data in geographically distant areas. If one site is destroyed, you can recover by utilizing the data stored in another site.
Actually a firewall that includes a VPN server and requires all traffic to connect via that VPN connection *would* help quite a lot. Everything going in and coming out would be encrypted gibberish - eliminating the possibility of most attacks - aside from attacking the VPN itself, a difficult proposition. WEP/WPA alone is not enough.
That being said, there is always an extra layer of security - you could (should) encrypt your plain-text messages using a one-time-pad (issued to every unit in the field for COMSEC purposes and switched out at a minimum of 24 hours). Additionally, if any computer system contained OPSEC material - that material better be encrypted if accessible from an external network (and I think a wireless would always qualify as 'accessible' for those purposes) or removed from the system. This is why those three letter government agencies have two computers on their desk - one touches the internal 'secure' network that has no gateways touching the internet, and a 'non-secure' network that allows them to read/.
Intel has a window of opportunity for exploitation - if you put an encrypted operational map (for example) on your vehicle's computer 1 hour before jump-off, I think that would be a low risk operation - assuming VPN tunneling (ideally with SecurID keys - a kind of one-time-pad that rotates on a minute by minute basis) and firewall locking down everything but the VPN traffic; while they might break the firewall, and they might get the file, by the time they do that *and* decrypt it - it will be too late to use the information. On the other hand, if there was an operations order for a given mission a month from now - that might be a different story.
No one wants to work on...some shambling, bloated monster of a program.
That wouldn't be a problem if you decouple the backend mechanics from the presentation/gui. Better yet - publish an API so third parties can build their own UIs to taste.
You can run an Apache/squid SLB pool in front of a Zope/Plone implementation (this is typically used to improve performance and provide an extra layer of security). So - there is no telling how many sites are actually Zope/Plone on the backend.
Flexibility is the hallmark of python/zope/plone....
My concern is what happens when we lose one of those mainframes with 100 virtual servers on it?
Either you better make sure that system won't go down (impossible given the vicissitudes of hardware), or you have another hot mainframe standing by to spin up all those server images on (and how long will that take?). Does anyone here have experience dealing with disaster recovery in a large-scale virtual server environment?
To paraphrase Mark Twain, "if you're going to keep all your eggs in one basket, you better make sure it is a darn good basket!"
Humans don't even get semantics right consistently. In many cases there is no one 'right' meaning for any given collection of symbols. It all resides within the human skull, and is ever changing over time - and is reflected in how languages and symbology morph through the centuries.
There have been various attempts to tame the semantic beast - formalized hierarchies being the most successful in conjunction with the advancement of scientific thought, and more recently less formalized meta-tagging systems. In these systems that seem to work best the human is involved in providing the meaning in terms a computer (or other humans) can understand: lists of keys/pointers to other lists ad infinitum. Of course there is always that undefineable exception that breaks such simple systems (e.g. the Platypus).
Reality is an ever changing and evolving continuum - and quantum physicists would probably take issue with that.
My macbook pro does fine with the latest games using bootcamp and XP - and my older games work great too. Games I've used on the Mac side (WOW, BattlefieldEurope) run great natively.
What I am jazzed about is the new 64 bit graphics/windowing code (basically extending the 64 bit code all the way from the kernel to the GUI). That coupled with the commitment of game manufacturers to port more games to the Mac could make the Apple platform a viable performance gamer's box.
The biggest LAG issue in the games I've played has not been my network - the bottleneck is most commonly the slowdown in rendering complex scenes in realtime (e.g. nearby explosions, large groups of players near, etc). My Intel core2duo macbook pro doesn't usually have serious problems in this regard - compared to my old Pentium 4 gamebox. If the rendering speed on the Mac turns out to be better than XP on the macbook, then I'll be buying more Mac specific games going forward.
My goal is to be able to extract all of my documentation from the source code. This keeps the version control simple - since you don't have to syncronize 10 documents as changes are made. There are various tools for doing this depending on your language of choice.
Perl has perldoc functionality built in - limited in some respects. Python has doc strings - but needs more processing to generate readable documentation beyond API lists. A more general purpose tool for generating documentation from source code is doxygen - currently supporting C++, C, Java, Objective-C, Python, IDL (Corba and Microsoft flavors) and to some extent PHP, C#, and D. There may be other tools that I am not aware of.
I've seen ads on TV for tiny toy helicopters and more interestingly - ornithopters that look like large dragonflys. They are radio or infrared controlled.
Someone could have been flying these over the crowd.
1. lack of toleration; unwillingness or refusal to tolerate or respect contrary opinions or beliefs, persons of different races or backgrounds, etc. 2. incapacity or indisposition to bear or endure.
- Random House Unabridged Dictionary
Rome didn't last forever either. A country is only as good as its citizens force it to be at any given moment in time. If you look at the history of the US - you see a constant struggle to protect the Constitution and the Bill of Rights - an ebb and flow of interpretations as conditions allowed or demanded. It takes wisdom and compassion to do that fairly. It takes the involvement of the people - people with a moral compass that leads them to do the right thing even if the road less traveled is a difficult one. The greatest strength of our nation has been the willingness to protect the rights of the minority - to tolerate different views, and have the flexibility to change when change was required - and conversely to hold the line when the pendulum swings wildly away from the plumb line of the common good.
There are several generations that come to mind - that had the will to stand - the generation of the American Revolution years, and the generation that fought WWII. Both were willing to sacrifice their lives in order to first form a novel form of government, then later to protect it from destruction. The Civil War, for that matter, could be seen as a correction to the Great Compromise - a point which shows that the founders were not perfect, and sadly one that led to war - a cautionary tale of where intolerance leads. The Civil Rights laws and protests of the 1960s was a less destructive completion of the Civil War that began a century before. It seems that people only show the best (and for that matter worse) of their character in times of ultimate distress - it is almost as if we can't see the train is coming until it is upon us. We only stand when it becomes unbearable - and destruction ensues.
My question is, will today's generations go down in history as protectors or destroyers of the great experiment that is the United States of America? Will we be a beacon of freedom for others, or a sad footnote of history? Will we sit on our hands until the destruction of civil war rips the fabric of the nation, or will we have the wisdom to settle conflicts peacefully (hold public policy makers to a higher standard)?
This can be mitigated in several ways without having to break the business model:
1. Expose the APIs used to access the device. This way the FOSS community can build an interface that will get the job done without using company resources.
2. Make the interface non-OS specific using standards. An http interface can be programmed once on the backend, and support multiple OSs via web browser (similar to how commodity IP router/switches are configured today).
These are ways of providing value add for the user, while at the same time saving your company money by only having to maintain one code base.
This is not rocket science - yet few people have the vision to make these things happen.
This can be mitigated in several ways without having to break the business model:
1. Expose the APIs used to access the device. This way the FOSS community can build an interface that will get the job done.
2. Make the interface non-OS specific using standards. An http interface can be programmed once on the backend, and support multiple OSs via web browser (similar to how commodity IP router/switches are configured today).
These are ways of providing value add for the user, while at the same time saving your company money by only having to maintain one code base. WIN-WIN!
I thought the iPod worked like any other USB drive - I don't need iTunes to put music on my thumb drive, I just mount it on the file system and transfer the files. Of course, I use MP3s exclusively - might it have something to do with Apple's proprietary music file format (.m4a et al)? I thought you could load regular files on your iPod too. An MP3 is just another file. If you can't play MP3s that you've uploaded to your iPod - you might as well buy another (cheaper) alternative that will let you do just that. What am I missing here?
I expect Apple will produce a linux iTunes executable for download - they already have one for Windows, so why not? It doesn't make any sense to block revenue - in the form of iTunes purchases - from an ever growing segment of your market. Of course Jobs did anger the iPhone early adopters by lowering prices - some would say prematurely, so it might not be a stretch to see them starting to get a bit of that Microsoft hubris as their market share grows...
In the interests of full disclosure I am both an OSX and Linux owner/user - with all that implies. I do not have an iPod (my Macbook is my mobile music system - although it's hell to jog with).
There has been gear like this for years - outfitter stores provide these capabilities - including solar stills, reverse osmosis filtration and the tried and true Iodine tables for a lot less than $350!
Sounds like someone is trying to make a buck at the expense of ignorant people. Of course, the site is/.'d so I can't verify his claims.
"More structured situations"? You don't know what you're putting in your DBMS? Data is structured, if it's not, then it's noise and you can't store it or identify it. Think about it.
I have thought about it - for years - dealing with venders and internal data modelers who assume that you can define every property of a given *changing* system before hand. When dealing with dynamic changing systems - you can not define 100% of the relationships - you can only make an approximation:
The information in the world is not composed of one set ontology, except in very proscribed areas. For the most part information is gathered and categorized on the fly - what is relevent to one group is not to another or even to the same group on different day - you will never be able to capture that in an RDBMS. Your framework is already irrelevant by the time you build it. You do not serve your users by stating 'data is king' - and leaving them without a solution.
Most information is like this - there is a very small subset that falls clearly into those categories that allow you to normalize the data nicely. Then there is the vast sea of information that is unclassifiable, or conversely is classified in various ways because of its volatility - all of which you want to capture.
In fact human beings think this way - we don't have a strict set of classifications for a given subject. We have many different and sometimes conflicting ideas about how things are related and how they are not. Chaos is a given, and RDBMSs can not deal with it as well as ODBMSs. RDBMS advocates have been telling me I can't do 'X' for years, and I just go forward and do it anyway using ODBMSs - and it works. Most of what I deal with can not effectively be managed in an RDBMS. From my perspective, RDBMSs will continue to be a smaller subset of my solutions when compared to ODBMSs. YMMV.
It must be nice to work in an environment where the structure of the data doesn't change for '100' years. I don't have that luxury
Wait, weren't you storing data from object-oriented languages before? Now you've just got BLOBs? No thanks, I'd like to look inside the objects when making queries.
Try looking inside of an MPEG, MP3 or JPEG - you will have a bit of meta information in a header, but the vast majority of the data is a blob. Most people are collecting information in these formats today - in fact I would say the vast majority of data is in these kinds of formats. You are basically saying 'if it isn't alphanumeric I'm not going to deal with it'. This illustrates perfectly, the close mindedness of the hard-core RDBMS crowd. The world is changing - you aren't going to stop it by sticking your nose in the air, and refusing to deal with it.
If there is a better way to deal with dynamic/changing systems and multimedia objects - please show me the light. From my own experience RDBMSs are not the solution.
There are so many different ways to do something in Perl that you end up doing what is expedient - but not maintainable over the long haul. On the other hand there is usually just one way to do a given thing in Python - which makes learning, and retaining the language much easier over time for me.
I've written production programs in Perl, awk, sed, Java, C(++), Pascal, sh, php, and tcl for many years - and Python is just better in every way imaginable (JIT bytecode compilation, speed of development and debugging, more logical and standardized libraries and easy creation of your own libraries, strong (duck) typing, more of a 'computer science'-ish approach to programming including functional programming constructs, the ability to extend the language via a well defined interface in C, and out of the box GUI development using TK - "batteries included" indeed - when coupled with Zope/ZODB for persistence and web development, even more so).
I am not saying you *can't* program well in the others - I am just saying it takes more control; control that most programmers do not have - particularly in the learning stages. Some never get it - and thus the abominations we see crawl from the dank cesspool that is the internet on an almost daily basis. Python enforces good programming practices, and minimizes the options for a developer to shoot himself in the foot - while retaining the power needed to get real work done. There are only a few situations I would not use Python (generally programming tasks that depend upon leveraging hardware - drivers and system kernels - where every CPU cycle counts).
1. Object-oriented databases are designed to work well with object-oriented programming languages such as Python, Java, C#, Visual Basic.NET, C++ and Smalltalk. This makes implimentation quick and easy - yet stable and scalable at the same time.
2. ODBMSs use exactly the same model as object-oriented programming languages.
3. It is also worth noting that object databases hold the record for the World's largest database (over 1000 Terabytes at Stanford Linear Accelerator Center).
4. Access to data can be faster because joins are often not needed (as in a tabular implementation of a relational database). This is because an object can be retrieved directly without a search, by following pointers (e.g. the objects are stored in trees for fast retrieval). Dynamic indexing schemes further speeds up retrieval of full text searches.
5. Provides data persistence to applications that are not necessarily 'always on' - e.g. HTTP based stateless applications.
I think RDBMSs will be around for some time -- but they will be relegated to more structured situations and smaller data sets. ODBMSs will take over where data is changing, persistence is critical, data types are mostly large binary objects with associated meta-data, and datasets are humongous.
Right now my favorite ODBMS is the ZODB (Zope Object Data Base) - an ODBMS system tightly integrated with both Python (implimented using Python's native 'pickle' object persistence functionality), and the Zope web application development system - which itself is built with and uses Python. You can learn more about Zope at Zope.org.
Slashdot Mirror
I agree it is the 'pot calling the kettle black' when folks like this complain about for-profit companies not releasing source code. I also agree that people and companies can similarly demand compensation for their work with whatever limitations they demand. Caveat emptor.
That being said, the status quo does not address the problem of independent verification. Another solution (and the solution mentioned in the editorial) is to instead of depending upon proprietary software, mathematicians should support open source projects (and the editorial writer mentioned in his 'full disclosure' that he was involved in just such a project) that by definition provide the opportunity to review code when questions of validity arise. And they will arise in all cases - regardless of whether the code is proprietary or FOSS:
I agree completely with this statement, and said as much in my parent post. The difference is that with open source the community has the opportunity to validate the code when questions arise (I'll say it again) which is not the case with proprietary software.
I am assuming you meet all the self defined qualifications to make such a statement? While something may be esoteric to you doesn't qualify it as 'gibberish'. This statement makes quite a lot of assumptions with little facts to back it up.
Again, more assumptions without facts.
Ditto.
The issue is not whether software companies should make their source code open - the real issue is should mathematicians accept proprietary applications as proof of theorums?
As pointed out in the editorial, software developers make mistakes, and this is true regardless of whether that developer is a proprietary software vendor, or a free/open source software project. There is one key difference however, the validity of any given proof can be determined independently when using free/open source code by the very nature of the product (availability of source code). There is no validation for proprietary software beyond the assurances of the company involved.
When mathematic theory becomes applied mathematics (such as the creation of buildings, bridges, aircraft, or thermonuclear devices), which proof would you prefer to hang your life upon - Microsoft's guarantee, or independent verification and peer review? This becomes ever more critical as we create more complex systems that can not be easily verified by hand, yet rushed into applied use by the expediency/efficiencies they deem to provide.
Or more importantly, how attribution should be applied when they do. Give credit where credit is due.
People have been using geothermal heat pumps for maintaining house temperature as a sustainable alternative to the traditional gas/electric air conditioner/furnace combination for years now (1 million installed base currently). A liquid is moved through pipes placed in the ground - in direct contact with earth or water - to remove the waste heat for cooling, and to absorb heat for warming.
While this approach may save money for the company, and is certainly a 'greener' approach than traditional data centers, there are other factors that make it a desirable solution:
1. Physical security. Getting into a mine is difficult - and generally accessible from one point - which can be controlled easier than an above ground structure.
2. EMP security. In the event of a nuclear war or similar event that could produce significant EMP, an underground site is your best bet. If wired properly, I am sure Sun's Black Boxes also serve as nice Faraday cages as an added bonus. Aside from a direct hit on the mineshaft, your data will be secure.
3. Geographical dispersion. Another component of disaster recovery is maintaining copies of your data in geographically distant areas. If one site is destroyed, you can recover by utilizing the data stored in another site.
Actually a firewall that includes a VPN server and requires all traffic to connect via that VPN connection *would* help quite a lot. Everything going in and coming out would be encrypted gibberish - eliminating the possibility of most attacks - aside from attacking the VPN itself, a difficult proposition. WEP/WPA alone is not enough.
/.
That being said, there is always an extra layer of security - you could (should) encrypt your plain-text messages using a one-time-pad (issued to every unit in the field for COMSEC purposes and switched out at a minimum of 24 hours). Additionally, if any computer system contained OPSEC material - that material better be encrypted if accessible from an external network (and I think a wireless would always qualify as 'accessible' for those purposes) or removed from the system. This is why those three letter government agencies have two computers on their desk - one touches the internal 'secure' network that has no gateways touching the internet, and a 'non-secure' network that allows them to read
Intel has a window of opportunity for exploitation - if you put an encrypted operational map (for example) on your vehicle's computer 1 hour before jump-off, I think that would be a low risk operation - assuming VPN tunneling (ideally with SecurID keys - a kind of one-time-pad that rotates on a minute by minute basis) and firewall locking down everything but the VPN traffic; while they might break the firewall, and they might get the file, by the time they do that *and* decrypt it - it will be too late to use the information. On the other hand, if there was an operations order for a given mission a month from now - that might be a different story.
That wouldn't be a problem if you decouple the backend mechanics from the presentation/gui. Better yet - publish an API so third parties can build their own UIs to taste.
You can run an Apache/squid SLB pool in front of a Zope/Plone implementation (this is typically used to improve performance and provide an extra layer of security). So - there is no telling how many sites are actually Zope/Plone on the backend.
Flexibility is the hallmark of python/zope/plone....
Thanks for the feedback!
My concern is what happens when we lose one of those mainframes with 100 virtual servers on it?
Either you better make sure that system won't go down (impossible given the vicissitudes of hardware), or you have another hot mainframe standing by to spin up all those server images on (and how long will that take?). Does anyone here have experience dealing with disaster recovery in a large-scale virtual server environment?
To paraphrase Mark Twain, "if you're going to keep all your eggs in one basket, you better make sure it is a darn good basket!"
Humans don't even get semantics right consistently. In many cases there is no one 'right' meaning for any given collection of symbols. It all resides within the human skull, and is ever changing over time - and is reflected in how languages and symbology morph through the centuries.
There have been various attempts to tame the semantic beast - formalized hierarchies being the most successful in conjunction with the advancement of scientific thought, and more recently less formalized meta-tagging systems. In these systems that seem to work best the human is involved in providing the meaning in terms a computer (or other humans) can understand: lists of keys/pointers to other lists ad infinitum. Of course there is always that undefineable exception that breaks such simple systems (e.g. the Platypus).
Reality is an ever changing and evolving continuum - and quantum physicists would probably take issue with that.
IL2 Stormovik rocks!
My macbook pro does fine with the latest games using bootcamp and XP - and my older games work great too. Games I've used on the Mac side (WOW, BattlefieldEurope) run great natively.
What I am jazzed about is the new 64 bit graphics/windowing code (basically extending the 64 bit code all the way from the kernel to the GUI). That coupled with the commitment of game manufacturers to port more games to the Mac could make the Apple platform a viable performance gamer's box.
The biggest LAG issue in the games I've played has not been my network - the bottleneck is most commonly the slowdown in rendering complex scenes in realtime (e.g. nearby explosions, large groups of players near, etc). My Intel core2duo macbook pro doesn't usually have serious problems in this regard - compared to my old Pentium 4 gamebox. If the rendering speed on the Mac turns out to be better than XP on the macbook, then I'll be buying more Mac specific games going forward.
My goal is to be able to extract all of my documentation from the source code. This keeps the version control simple - since you don't have to syncronize 10 documents as changes are made. There are various tools for doing this depending on your language of choice.
Perl has perldoc functionality built in - limited in some respects. Python has doc strings - but needs more processing to generate readable documentation beyond API lists. A more general purpose tool for generating documentation from source code is doxygen - currently supporting C++, C, Java, Objective-C, Python, IDL (Corba and Microsoft flavors) and to some extent PHP, C#, and D. There may be other tools that I am not aware of.
Keep it simple.
Yes, but that also leaves traces of DNA...
I've seen ads on TV for tiny toy helicopters and more interestingly - ornithopters that look like large dragonflys. They are radio or infrared controlled.
Someone could have been flying these over the crowd.
Rome didn't last forever either. A country is only as good as its citizens force it to be at any given moment in time. If you look at the history of the US - you see a constant struggle to protect the Constitution and the Bill of Rights - an ebb and flow of interpretations as conditions allowed or demanded. It takes wisdom and compassion to do that fairly. It takes the involvement of the people - people with a moral compass that leads them to do the right thing even if the road less traveled is a difficult one. The greatest strength of our nation has been the willingness to protect the rights of the minority - to tolerate different views, and have the flexibility to change when change was required - and conversely to hold the line when the pendulum swings wildly away from the plumb line of the common good.
There are several generations that come to mind - that had the will to stand - the generation of the American Revolution years, and the generation that fought WWII. Both were willing to sacrifice their lives in order to first form a novel form of government, then later to protect it from destruction. The Civil War, for that matter, could be seen as a correction to the Great Compromise - a point which shows that the founders were not perfect, and sadly one that led to war - a cautionary tale of where intolerance leads. The Civil Rights laws and protests of the 1960s was a less destructive completion of the Civil War that began a century before. It seems that people only show the best (and for that matter worse) of their character in times of ultimate distress - it is almost as if we can't see the train is coming until it is upon us. We only stand when it becomes unbearable - and destruction ensues.
My question is, will today's generations go down in history as protectors or destroyers of the great experiment that is the United States of America? Will we be a beacon of freedom for others, or a sad footnote of history? Will we sit on our hands until the destruction of civil war rips the fabric of the nation, or will we have the wisdom to settle conflicts peacefully (hold public policy makers to a higher standard)?
I was going to say:
'Once this is done this will be a very impressive city in terms of public surveilance(sic)'
This can be mitigated in several ways without having to break the business model:
1. Expose the APIs used to access the device. This way the FOSS community can build an interface that will get the job done without using company resources.
2. Make the interface non-OS specific using standards. An http interface can be programmed once on the backend, and support multiple OSs via web browser (similar to how commodity IP router/switches are configured today).
These are ways of providing value add for the user, while at the same time saving your company money by only having to maintain one code base.
This is not rocket science - yet few people have the vision to make these things happen.
This can be mitigated in several ways without having to break the business model:
1. Expose the APIs used to access the device. This way the FOSS community can build an interface that will get the job done.
2. Make the interface non-OS specific using standards. An http interface can be programmed once on the backend, and support multiple OSs via web browser (similar to how commodity IP router/switches are configured today).
These are ways of providing value add for the user, while at the same time saving your company money by only having to maintain one code base. WIN-WIN!
I thought the iPod worked like any other USB drive - I don't need iTunes to put music on my thumb drive, I just mount it on the file system and transfer the files. Of course, I use MP3s exclusively - might it have something to do with Apple's proprietary music file format (.m4a et al)? I thought you could load regular files on your iPod too. An MP3 is just another file. If you can't play MP3s that you've uploaded to your iPod - you might as well buy another (cheaper) alternative that will let you do just that. What am I missing here?
I expect Apple will produce a linux iTunes executable for download - they already have one for Windows, so why not? It doesn't make any sense to block revenue - in the form of iTunes purchases - from an ever growing segment of your market. Of course Jobs did anger the iPhone early adopters by lowering prices - some would say prematurely, so it might not be a stretch to see them starting to get a bit of that Microsoft hubris as their market share grows...
In the interests of full disclosure I am both an OSX and Linux owner/user - with all that implies. I do not have an iPod (my Macbook is my mobile music system - although it's hell to jog with).
Someone will port that to Darwin, I'm sure.
There has been gear like this for years - outfitter stores provide these capabilities - including solar stills, reverse osmosis filtration and the tried and true Iodine tables for a lot less than $350!
/.'d so I can't verify his claims.
Sounds like someone is trying to make a buck at the expense of ignorant people. Of course, the site is
I don't know what 'slader' is. "You keep saying that word. I do not think it means what you think it means." - Inigo Montoya
I have thought about it - for years - dealing with venders and internal data modelers who assume that you can define every property of a given *changing* system before hand. When dealing with dynamic changing systems - you can not define 100% of the relationships - you can only make an approximation:
The information in the world is not composed of one set ontology, except in very proscribed areas. For the most part information is gathered and categorized on the fly - what is relevent to one group is not to another or even to the same group on different day - you will never be able to capture that in an RDBMS. Your framework is already irrelevant by the time you build it. You do not serve your users by stating 'data is king' - and leaving them without a solution.
Most information is like this - there is a very small subset that falls clearly into those categories that allow you to normalize the data nicely. Then there is the vast sea of information that is unclassifiable, or conversely is classified in various ways because of its volatility - all of which you want to capture.
In fact human beings think this way - we don't have a strict set of classifications for a given subject. We have many different and sometimes conflicting ideas about how things are related and how they are not. Chaos is a given, and RDBMSs can not deal with it as well as ODBMSs. RDBMS advocates have been telling me I can't do 'X' for years, and I just go forward and do it anyway using ODBMSs - and it works. Most of what I deal with can not effectively be managed in an RDBMS. From my perspective, RDBMSs will continue to be a smaller subset of my solutions when compared to ODBMSs. YMMV.
It must be nice to work in an environment where the structure of the data doesn't change for '100' years. I don't have that luxury
Try looking inside of an MPEG, MP3 or JPEG - you will have a bit of meta information in a header, but the vast majority of the data is a blob. Most people are collecting information in these formats today - in fact I would say the vast majority of data is in these kinds of formats. You are basically saying 'if it isn't alphanumeric I'm not going to deal with it'. This illustrates perfectly, the close mindedness of the hard-core RDBMS crowd. The world is changing - you aren't going to stop it by sticking your nose in the air, and refusing to deal with it.
If there is a better way to deal with dynamic/changing systems and multimedia objects - please show me the light. From my own experience RDBMSs are not the solution.
I would say the same thing about Python vs. Perl.
There are so many different ways to do something in Perl that you end up doing what is expedient - but not maintainable over the long haul. On the other hand there is usually just one way to do a given thing in Python - which makes learning, and retaining the language much easier over time for me.
I've written production programs in Perl, awk, sed, Java, C(++), Pascal, sh, php, and tcl for many years - and Python is just better in every way imaginable (JIT bytecode compilation, speed of development and debugging, more logical and standardized libraries and easy creation of your own libraries, strong (duck) typing, more of a 'computer science'-ish approach to programming including functional programming constructs, the ability to extend the language via a well defined interface in C, and out of the box GUI development using TK - "batteries included" indeed - when coupled with Zope/ZODB for persistence and web development, even more so).
I am not saying you *can't* program well in the others - I am just saying it takes more control; control that most programmers do not have - particularly in the learning stages. Some never get it - and thus the abominations we see crawl from the dank cesspool that is the internet on an almost daily basis. Python enforces good programming practices, and minimizes the options for a developer to shoot himself in the foot - while retaining the power needed to get real work done. There are only a few situations I would not use Python (generally programming tasks that depend upon leveraging hardware - drivers and system kernels - where every CPU cycle counts).
YMMV.
I think the object database management system (ODBMS) will overtake RDBMSs in the future for several reasons (from the link and my own musings):
.NET, C++ and Smalltalk. This makes implimentation quick and easy - yet stable and scalable at the same time.
1. Object-oriented databases are designed to work well with object-oriented programming languages such as Python, Java, C#, Visual Basic
2. ODBMSs use exactly the same model as object-oriented programming languages.
3. It is also worth noting that object databases hold the record for the World's largest database (over 1000 Terabytes at Stanford Linear Accelerator Center).
4. Access to data can be faster because joins are often not needed (as in a tabular implementation of a relational database). This is because an object can be retrieved directly without a search, by following pointers (e.g. the objects are stored in trees for fast retrieval). Dynamic indexing schemes further speeds up retrieval of full text searches.
5. Provides data persistence to applications that are not necessarily 'always on' - e.g. HTTP based stateless applications.
I think RDBMSs will be around for some time -- but they will be relegated to more structured situations and smaller data sets. ODBMSs will take over where data is changing, persistence is critical, data types are mostly large binary objects with associated meta-data, and datasets are humongous.
Right now my favorite ODBMS is the ZODB (Zope Object Data Base) - an ODBMS system tightly integrated with both Python (implimented using Python's native 'pickle' object persistence functionality), and the Zope web application development system - which itself is built with and uses Python. You can learn more about Zope at Zope.org.