It's not different from what you said, but you make it sound incredibly easy and as though it's automatic. Promoting open source software is just as, if not more so, important as for closed software.
The point is, I'd love to have lots of people use my software. It's _good_ software. But people don't use it until it's worth using. And people don't patch it if they're not using it. It's kind of a catch 22 situation. So saying "don't do things if you don't want them" is all well and good if you want people to go elsewhere for their software - maybe to a closed source package. But if you want people to use what you produce, and obtain that critical mass, there's a lot of effort goes in before that occurs.
And the old 300-liner application doesn't quite count, IMHO. Apps like that are easy to patch, and often only require small fixes, and are never going to grow into much larger apps. The packages I'm talking about in my comment run into the thousands of lines, and to improve require that intimate knowledge that only either large numbers of users or the sole developer can bring to the table.
It seems you have an incredibly naive view, although that view is supported - it's the philosophy of how open source works. But in reality it's a whole different picture... What tends to happen instead is things stop at point 1, unless your code is already at point 4, so you end up spending hours, weeks, months, writing your code, improving it, fixing it, promoting it, and still no patches come in. Eventually you get to point 4 yourself, if you put in the effort.
But that's OK - because you've got a great product that people use. I have a couple myself that I'm very proud of. But patches are extremely rare until you hit a really large critical mass. Take all my open source projects combined (XML::XPath, DBIx::AnyDBD, AxKit, CGI::XMLForm, DBIx::XML_RDB, Time::Object, XML::PYX and Win32::ASP - all Perl based, all (most) used quite a lot). I recieve about 1 or 2 patches a year (in total - not per project). Thats not a whole lot, and not enough to keep a project going without me.
I'm not complaining though - these projects not only scratch my itch, but they were/are fun. I still get the "open sauce kudos" - although it's not as prevalent as ESR makes out in CatB.
The point of this is: Patches do _not_ happen until there is critical mass. And critical mass is a lot bigger than some people believe. (although the argument is probably moot for slashdot and sourceforge - if they're already getting patches they've probably achieved critical mass!)
I'm guessing you're an ex (or current) Amiga user. This is how for so many years, despite inferior hardware, the Amiga managed to pull of some amazing graphics feats.
I seriously hope that the X team take your post _very_ seriously indeed.
Still, he says that his company is thinking seriously about converting its mail server back from Linux to Windows NT. Group Logic has documented several cases where the sendmail program running on the Linux server lost an e-mail message. While it's had few other problems with Linux, he says the software is still difficult for much of the staff to manage; Windows NT is just easier for most of them to use and reconfigure. According to Newberry, saving the cost of a Windows NT license just isn't worth it.
I don't understand this attitude. If one package is broken you don't install a whole different OS! Get a mail server that guarantees mail delivery, like QMail!
I'm not trolling, this really is a good option for any database app. Write an application that carefully uses DBI, doesn't make too many assumptions about the file system, and use DBIx::AnyDBD, and you've got an application that's not only portable between Unix, Win32 and probably MacOS, but also portable across different databases with a few trivial changes (provided you use DBIx::AnyDBD).
Not only that, but the Perl DBI drivers are written mostly in C, and interface directly to the underlying driver, rather than go through another layer like ODBC (unless of course you use DBD::ODBC or DBD::ADO). This means that any database bound app (one that is limited in speed by the underlying database) is going to run at a very similar speed to your C application.
Since XML is going to be such a huge part of the industry within a year or two, what I think that Linux (and indeed, every operating system that wants to compete) needs to do is to integrate XML into the kernel as an intrinsic part of the system architecture. Then software vendors, looking for a rock-solid platform with which to write mission-critical apps in the internet able domain, will choose Linux as their platform of choice, since having XML integrated into the kernel will provide stability and performance attributes.
I say I've never heard such horse s**t before. Integrating an XML parser into the kernel will do exactly zero for the performance of XML parsing. This is a userland task. It's fairly obvious that you know nothing about XML, nothing about kernels, and I'm guessing these "top names" didn't do enough research about your knowledge before asking you to do their report. I look forward to seeing it headline on ZDNet.
Want to deliver XML with Apache to different media in varying styles? Get AxKit
Sadly there are still barriers to this becoming a reality (although I really hope it does become a reality). Perhaps the biggest barrier is the lack of really good XML authoring tools. I really believe that the first company releasing a first class DocBook/XML editor for a price under $100 will make an absolute killing in the marketplace. Current offerings such as add-on modules for Word, FrameMaker/SGML, and WP/SGML just don't quite cut the mustard. XMetaL Pro looks pretty good, I hope the next version will be better.
In short, I expect to see this sort of tool become a reality in this season's software releases.
Other barriers to this also include decent formatting. We have reasonable XSLT styles for DocBook, but completely modifying these to make a custom look and feel is still pretty hard. Someone is going to release an XSLT WYSIWYG editor real soon now and make another killing in the market.
So in summary, I think yes, XML can and will replace proprietary formats. And ultimately be easier to work with.
Want to deliver XML with Apache to varying media devices in different styles? Get AxKit
Microsoft want you to believe that they are buzword compliant, but in reality the output from Microsoft's "Save As HTML" looks like XML, smells like XML, but isn't. Try parsing it.
See the recent Byte article "The cup is half full" for more details. I'm surprised you haven't heard about this. MS is using it's proprietary XML Islands inside a HTML document. That means you have to get a HTML parser to be able to parse it. The content of the XML is just as proprietary. It's basically a conversion of their OLE Document objects into XML.
This idea is how these MP3 pirates are currently justifying their actions (of course, being pirates, they're doing it without actually sending any money!). But it doesn't work.
One of the reasons these artists have record companies behind them is to shield them from all the money involved - so that they just get a paycheck going into their bank at the end of the year/quarter/month/whatever. I can't honestly see a major act thinking it's really cool that they get 10,000 snail mails a month with $5 in the envelope. That would just drive you insane. You'd need a secretary, and an accountant, and people to open all the mail, and... oh wait... all that infrastructure - might as well have a record label!
Then you could potentially streamline it: build a web site that accepts payments... but wait, someone has to build the web site, pay for a Verisign certificate, market the site, pay for advertising, maintain the site, oh wait... all that infrastructure - might as well have some other company do all that, and they can take a percentage of the profits...
You see, the infrastructure thats in place is there for a reason. It appeared for a reason. It may not be perfect, but stealing copyrighted materials isn't going to change that infrastructure.
I can't resist posting this, although it doesn't really answer your question about a point and click interface, it may help you develop something similar...
If you have Perl skills, then you may be interested in the Apache XML Delivery Toolkit. It's a suite of modules that help you with the following:
- Delivering XML to web browsers in a desired format. - Delivering the same page in different styles - Delivering the same page to different media (e.g handhelds (WAP), browsers, tty's, etc). - Developing a consistent style across your site.
It's all built around mod_perl, and it works in much the same way as Cocoon does, except that it's built in Perl, not Java.
I've got an X.21 leased line coming into my house. I consider myself quite lucky to have it. No "online/offline" hours. However I sure pay for it. It's £350 a month plus VAT (which I don't pay, but still...). Wait for it... for 64Kb/s. That's Kb, not KB too!
Yes, I'm very jealous of everyone in the US for their cheap access, and yes, I have considered moving because of it!
The problem is twofold: BT is held back in part by being extremely money grabbing - they are (I think) the richest company in the country, and one of the richest companies in the world. They are also held back by their stock holders, who see the release of DSL in this country as a turning point - all those people paying up to 4p a minute on local phone access to the net will suddenly be paying a flat rate monthly fee. This is gonna hurt BT. Hence the ridiculous prices.
And yes, BT could have rolled this out much much sooner. They have the resources and the infrastructure. Don't believe otherwise. They have the infrastructure for everyone to have X.21 in their homes too - but the money they'd lose rolling that out prevents them from making it the price it should be.
And hit them over the head with it, until all thoughts of MS Access finally leave their bleeding pulverised bodies.;-)
Seriously - MS Access is not safe enough for live web use, so I assume you're hoping there might be some porting tool to convert MS Access DB's to PHP + MySQL. I think you've reached the conclusion that there isn't, so it's time to reach for that stick.
Get yourself a copy of Jon Udell's "Practical Internet Groupware". It includes a really good discussion of all the issues involved here, including getting people actually talking on these sort of lists, what scope lists should have, and how to actually go about implementing the (in case you don't know already).
Firstly, Outlook sometimes puts the attachment in the body. That's just how it works. If you don't want it to happen you'll have to specify a MIME type it doesn't recognise, or zip up your file. It will do this with HTML or text attachments. Netscape Messenger does the same thing.
Having said all that, Mail::Sender works extremely well, even if the code is a bit spaghetti-ish. And does attachments just fine.
PerlFS is a linux kernel module that embeds perl so you can build file systems in Perl. Very cool technology, as you can actually build an ftp filesystem or a http filesystem, or all manner of cool things. Just don't add in any XS modules or your kernel might go kaboom... Ah well.
For starters, I don't think "most" computer professionals are equipped with a laptop by their employer. Certainly not developers. Maybe account managers, or tech support.
Secondly - I really really think its pretty sad if you take your laptop on holiday with you... Man - YOU'RE ON HOLIDAY!!! I don't even take my palm pilot on holiday with me.
Finally - pretty much only if you go on holiday within your own country are you going to find identical plug sockets and voltages (e.g. England is on 240V, Europe is on 220V, and the US/Canada are on 110V). I'd rather go somewhere exotic that I can't plug anything into. However if I went somewhere exotic I probably couldn't get floppys for the Mavica either;-)
(yes, I know all about voltage adaptors, etc. The bigger point was about "Leave it at home!").
I think it's going to be a little more fine grained than that - sort of like how noone now records their home movies onto film - the magnetic storage methods are cheaper and simpler... However, there is always a class of people (i.e. professionals) who will always need _real_ film.
I think the same will happen with digital cameras. The old fashioned point and shoot cameras will simply all but disappear, and we'll be left with a choice of digital cameras or high end SLR cameras that professionals (or hobbyists) use. I think there will also be an option to have your digital COMPACTflash card processed at the chemists into glossies.
OK, back on topic... I think there's something still to be said for the Sony Mavica. While floppy's don't hold all that many high quality pictures, there's something to be said if you're on holiday and you fill up your disk - you can just buy a new pack of ten floppys!
This is yet another vertical market that Open Source has yet to really break into. And why should it? It's hardly an easy itch to scratch - the problems these companies have been working to solve they've been working on for years.
See also the "Ask Slashdot" about enterprise level RDBMS's.
I think you're not the only one, judging by the python luvers who have moderated you up;-)
But are you saying that a language designed to do one thing should forever remain just to do that one thing?
You think perl's OO features aren't elegant. I think the opposite - they so neatly fit into the language that it's hard to believe that they are so simple (bless $ref; # whoaa - it's an object now).
Perl does need a _bit_ of a rethink, but that rethink won't be to reduce perl back to just a reporting language - it will be to make perl more powerful. To provide threading or multiple interpreters from the ground up. To provide exceptions built into the core. To make compiled extensions a bit easier. To make classes have named attributes (not the monstrosity that is "use fields"). To make signal handling safe.
These things are being thought about, and are being dealt with, but don't expect miracles any time soon.
The Win32::OLE module has to do quite a few syntax changes to make it work like the VBScrypt or JScrypt implementations of OLE (the significance of this is in ASP use). However with lvalue subs this is no longer the case. Irritating VBScript things like:
Object.Collection('Key') = Value
Can now be implemented in perl using the very similar syntax:
$Object->Collection('Key') = $Value;
So I think lvalue subs will have a lot of uses. They will also go a long way to allowing overriding of all core functions, although that's still a way away yet (something python does far more elegantly than perl).
How can we? You use Zope. Telnets get through, pings get through. The only damn thing that won't go through is HTTP. Perhaps you should investigate a more scale-able solution?;-)
Slashdot Mirror
It's not different from what you said, but you make it sound incredibly easy and as though it's automatic. Promoting open source software is just as, if not more so, important as for closed software.
The point is, I'd love to have lots of people use my software. It's _good_ software. But people don't use it until it's worth using. And people don't patch it if they're not using it. It's kind of a catch 22 situation. So saying "don't do things if you don't want them" is all well and good if you want people to go elsewhere for their software - maybe to a closed source package. But if you want people to use what you produce, and obtain that critical mass, there's a lot of effort goes in before that occurs.
And the old 300-liner application doesn't quite count, IMHO. Apps like that are easy to patch, and often only require small fixes, and are never going to grow into much larger apps. The packages I'm talking about in my comment run into the thousands of lines, and to improve require that intimate knowledge that only either large numbers of users or the sole developer can bring to the table.
It seems you have an incredibly naive view, although that view is supported - it's the philosophy of how open source works. But in reality it's a whole different picture... What tends to happen instead is things stop at point 1, unless your code is already at point 4, so you end up spending hours, weeks, months, writing your code, improving it, fixing it, promoting it, and still no patches come in. Eventually you get to point 4 yourself, if you put in the effort.
But that's OK - because you've got a great product that people use. I have a couple myself that I'm very proud of. But patches are extremely rare until you hit a really large critical mass. Take all my open source projects combined (XML::XPath, DBIx::AnyDBD, AxKit, CGI::XMLForm, DBIx::XML_RDB, Time::Object, XML::PYX and Win32::ASP - all Perl based, all (most) used quite a lot). I recieve about 1 or 2 patches a year (in total - not per project). Thats not a whole lot, and not enough to keep a project going without me.
I'm not complaining though - these projects not only scratch my itch, but they were/are fun. I still get the "open sauce kudos" - although it's not as prevalent as ESR makes out in CatB.
The point of this is: Patches do _not_ happen until there is critical mass. And critical mass is a lot bigger than some people believe. (although the argument is probably moot for slashdot and sourceforge - if they're already getting patches they've probably achieved critical mass!)
How Things Work.
I have to actually thank you too - I'd forgotten about this site, and it really is one of the cooler sites on the net.
I'm guessing you're an ex (or current) Amiga user. This is how for so many years, despite inferior hardware, the Amiga managed to pull of some amazing graphics feats.
I seriously hope that the X team take your post _very_ seriously indeed.
I don't understand this attitude. If one package is broken you don't install a whole different OS! Get a mail server that guarantees mail delivery, like QMail!
I'm not trolling, this really is a good option for any database app. Write an application that carefully uses DBI, doesn't make too many assumptions about the file system, and use DBIx::AnyDBD, and you've got an application that's not only portable between Unix, Win32 and probably MacOS, but also portable across different databases with a few trivial changes (provided you use DBIx::AnyDBD).
Not only that, but the Perl DBI drivers are written mostly in C, and interface directly to the underlying driver, rather than go through another layer like ODBC (unless of course you use DBD::ODBC or DBD::ADO). This means that any database bound app (one that is limited in speed by the underlying database) is going to run at a very similar speed to your C application.
Its just a thought. Try it, you might like it.
Since XML is going to be such a huge part of the industry within a year or two, what I think that Linux (and indeed, every operating system that wants to compete) needs to do is to integrate XML into the kernel as an intrinsic part of the system architecture. Then software vendors, looking for a rock-solid platform with which to write mission-critical apps in the internet able domain, will choose Linux as their platform of choice, since having XML integrated into the kernel will provide stability and performance attributes.
I say I've never heard such horse s**t before. Integrating an XML parser into the kernel will do exactly zero for the performance of XML parsing. This is a userland task. It's fairly obvious that you know nothing about XML, nothing about kernels, and I'm guessing these "top names" didn't do enough research about your knowledge before asking you to do their report. I look forward to seeing it headline on ZDNet.
Want to deliver XML with Apache to different media in varying styles? Get AxKit
In short, I expect to see this sort of tool become a reality in this season's software releases.
Other barriers to this also include decent formatting. We have reasonable XSLT styles for DocBook, but completely modifying these to make a custom look and feel is still pretty hard. Someone is going to release an XSLT WYSIWYG editor real soon now and make another killing in the market.
So in summary, I think yes, XML can and will replace proprietary formats. And ultimately be easier to work with.
Want to deliver XML with Apache to varying media devices in different styles? Get AxKit
No, it hasn't (already happened).
Microsoft want you to believe that they are buzword compliant, but in reality the output from Microsoft's "Save As HTML" looks like XML, smells like XML, but isn't. Try parsing it.
See the recent Byte article "The cup is half full" for more details. I'm surprised you haven't heard about this. MS is using it's proprietary XML Islands inside a HTML document. That means you have to get a HTML parser to be able to parse it. The content of the XML is just as proprietary. It's basically a conversion of their OLE Document objects into XML.
This idea is how these MP3 pirates are currently justifying their actions (of course, being pirates, they're doing it without actually sending any money!). But it doesn't work.
... oh wait... all that infrastructure - might as well have a record label!
One of the reasons these artists have record companies behind them is to shield them from all the money involved - so that they just get a paycheck going into their bank at the end of the year/quarter/month/whatever. I can't honestly see a major act thinking it's really cool that they get 10,000 snail mails a month with $5 in the envelope. That would just drive you insane. You'd need a secretary, and an accountant, and people to open all the mail, and
Then you could potentially streamline it: build a web site that accepts payments... but wait, someone has to build the web site, pay for a Verisign certificate, market the site, pay for advertising, maintain the site, oh wait... all that infrastructure - might as well have some other company do all that, and they can take a percentage of the profits...
You see, the infrastructure thats in place is there for a reason. It appeared for a reason. It may not be perfect, but stealing copyrighted materials isn't going to change that infrastructure.
If you have Perl skills, then you may be interested in the Apache XML Delivery Toolkit. It's a suite of modules that help you with the following:
- Delivering XML to web browsers in a desired format.
- Delivering the same page in different styles
- Delivering the same page to different media (e.g handhelds (WAP), browsers, tty's, etc).
- Developing a consistent style across your site.
It's all built around mod_perl, and it works in much the same way as Cocoon does, except that it's built in Perl, not Java.
If you're interested, take a peek at http://xml.sergeant.org/axdtk/.
I've got an X.21 leased line coming into my house. I consider myself quite lucky to have it. No "online/offline" hours. However I sure pay for it. It's £350 a month plus VAT (which I don't pay, but still...). Wait for it... for 64Kb/s. That's Kb, not KB too!
Yes, I'm very jealous of everyone in the US for their cheap access, and yes, I have considered moving because of it!
The problem is twofold: BT is held back in part by being extremely money grabbing - they are (I think) the richest company in the country, and one of the richest companies in the world. They are also held back by their stock holders, who see the release of DSL in this country as a turning point - all those people paying up to 4p a minute on local phone access to the net will suddenly be paying a flat rate monthly fee. This is gonna hurt BT. Hence the ridiculous prices.
And yes, BT could have rolled this out much much sooner. They have the resources and the infrastructure. Don't believe otherwise. They have the infrastructure for everyone to have X.21 in their homes too - but the money they'd lose rolling that out prevents them from making it the price it should be.
And hit them over the head with it, until all thoughts of MS Access finally leave their bleeding pulverised bodies. ;-)
Seriously - MS Access is not safe enough for live web use, so I assume you're hoping there might be some porting tool to convert MS Access DB's to PHP + MySQL. I think you've reached the conclusion that there isn't, so it's time to reach for that stick.
Get yourself a copy of Jon Udell's "Practical Internet Groupware". It includes a really good discussion of all the issues involved here, including getting people actually talking on these sort of lists, what scope lists should have, and how to actually go about implementing the (in case you don't know already).
It's an O'Reilly book, should be easy to find.
Firstly, Outlook sometimes puts the attachment in the body. That's just how it works. If you don't want it to happen you'll have to specify a MIME type it doesn't recognise, or zip up your file. It will do this with HTML or text attachments. Netscape Messenger does the same thing.
Having said all that, Mail::Sender works extremely well, even if the code is a bit spaghetti-ish. And does attachments just fine.
The Perl Filesystem
For starters, I don't think "most" computer professionals are equipped with a laptop by their employer. Certainly not developers. Maybe account managers, or tech support.
;-)
Secondly - I really really think its pretty sad if you take your laptop on holiday with you... Man - YOU'RE ON HOLIDAY!!! I don't even take my palm pilot on holiday with me.
Finally - pretty much only if you go on holiday within your own country are you going to find identical plug sockets and voltages (e.g. England is on 240V, Europe is on 220V, and the US/Canada are on 110V). I'd rather go somewhere exotic that I can't plug anything into. However if I went somewhere exotic I probably couldn't get floppys for the Mavica either
(yes, I know all about voltage adaptors, etc. The bigger point was about "Leave it at home!").
I think it's going to be a little more fine grained than that - sort of like how noone now records their home movies onto film - the magnetic storage methods are cheaper and simpler... However, there is always a class of people (i.e. professionals) who will always need _real_ film.
I think the same will happen with digital cameras. The old fashioned point and shoot cameras will simply all but disappear, and we'll be left with a choice of digital cameras or high end SLR cameras that professionals (or hobbyists) use. I think there will also be an option to have your digital COMPACTflash card processed at the chemists into glossies.
OK, back on topic... I think there's something still to be said for the Sony Mavica. While floppy's don't hold all that many high quality pictures, there's something to be said if you're on holiday and you fill up your disk - you can just buy a new pack of ten floppys!
This is yet another vertical market that Open Source has yet to really break into. And why should it? It's hardly an easy itch to scratch - the problems these companies have been working to solve they've been working on for years.
See also the "Ask Slashdot" about enterprise level RDBMS's.
I think you're not the only one, judging by the python luvers who have moderated you up ;-)
But are you saying that a language designed to do one thing should forever remain just to do that one thing?
You think perl's OO features aren't elegant. I think the opposite - they so neatly fit into the language that it's hard to believe that they are so simple (bless $ref; # whoaa - it's an object now).
Perl does need a _bit_ of a rethink, but that rethink won't be to reduce perl back to just a reporting language - it will be to make perl more powerful. To provide threading or multiple interpreters from the ground up. To provide exceptions built into the core. To make compiled extensions a bit easier. To make classes have named attributes (not the monstrosity that is "use fields"). To make signal handling safe.
These things are being thought about, and are being dealt with, but don't expect miracles any time soon.
The Win32::OLE module has to do quite a few syntax changes to make it work like the VBScrypt or JScrypt implementations of OLE (the significance of this is in ASP use). However with lvalue subs this is no longer the case. Irritating VBScript things like:
Object.Collection('Key') = Value
Can now be implemented in perl using the very similar syntax:
$Object->Collection('Key') = $Value;
So I think lvalue subs will have a lot of uses. They will also go a long way to allowing overriding of all core functions, although that's still a way away yet (something python does far more elegantly than perl).
Check the default prefs.js - it's an option you can enable. It's just enabled by default on Unix.
How can we? You use Zope. Telnets get through, pings get through. The only damn thing that won't go through is HTTP. Perhaps you should investigate a more scale-able solution? ;-)
Don't forget: XML was designed from the ground up for multilingual support, via the xml:lang attribute. Use that, not some invented tag!!!