Javascript, more properly DHTML, is amazingly better than it was at the height of the browser wars. Compare Danny Goodman's DHTML Definitive Guide 1st and 2nd editions. The first one is all about how to handle the differences between Netscape and MS. The 2nd is all about documenting the *standard* DOM and how to script it. MUCH easier than it was 5 years (or 3 years) ago.
Java applets are slow -- no argument there, but hello? Sun? Java is controlled nearly as tightly as Flash. And if you read Macromedia's marketing, they're basically presenting Flash as the Visual Basic of the web. Love or hate VB, it certainly made it easier to build applications. Something similar for the web would have a similar effect -- increased ability for developers to write great apps and increasingly crappy code from non-developers who think they're developers since easy GUI tools lower the barrier to entry for development projects.
Abuse of the technology -- cookie abuse, popups, etc -- is not the fault of the browser. tech is tech, use is use.
And I'm no fan of Microsoft, but Internet Explorer is a *great* browser. Again, wind the clock back 5, or even 3 years. And 6.x is now the last of it's kind before MS rolls it back into the OS.
Exactly what Jakarta subprojects would you suggest for building an ERP system? Or CRM? Compiere? Please.
I just spent 7 months with Epicor (ERP and CRM), which is one amazingly crappy piece of software. But where's the open source choice? I mean there's not even a viable OSS replacement for Quicken let alone a ERP, CRM, or real accounting system.
If you want tons of consulting bucks, write a *good* open source ERP or CRM platform and sell the consulting/support/training. But until there's a decent *enterprise* choice, we're stuck with the crap from the vendors.
One IT manager told me "All ERP solutions suck. And whichever one you choose sucks worst.":)
Wow -- not sure why this is even posted. ProTools has been the industry standard for years. On Mac no less. Now the MBox (the $495 combo of ProTools for MBox and a digital audio interface) make it cheaper than ever to do professional digital audio BUT there's a huge number of costs the poster didn't take into account for the cost of making an album:
Other software: software instruments, software effects processors, etc
Other digital hardware: audio interfaces, midi interfaces, mLAN interfaces
Other studio hardware: effects processors, mixers, etc, etc.
microphones
Instruments
Musicians
Of course the discussion about record labels, etc is right on as far as why CDs cost so much, but my twofold point is:
1) ProTools has been making music cheaper/better for years
2) ProTools alone can't make a single sound -- you need plenty of other gear
Good open source tools have 3rd party support, just like good closed source tools.
I can get Cisco/Oracle/MS/whatever corporate folks to support me directly or get an authorized partner to do the support. Open source projects that make headway in the enterprise either offer "vendor" support (eg MySQL AB, JBoss) through a consulting arm or through good grassroots 3rd party support that just pops up when the market can bear it.
The best way to knock over oracle is to start up a company that supports open source for a fee
MySQL AB does this already. Postgres has a similar but smaller plan in place. RedHat is another example in a non-db arena.
I see people using open source they can get support for -- it's that simple. JBoss is #3 depending on who you talk to. MySQL is gaining ground. Plenty of security tools are in the enterprise as well.
SQL injection *does* happen. I've seen it and plenty of web developers are not very SQL-savvy.
Try these two phpnuke sql injection vulnerabilities (1,2) for example from this week's securityfocus.com vulnerability list. Those are just a couple from the open source world.
In early 2000, my dotcom would allow points to be redeemed for Flooz (remember them?) which could then be used at among other place, Tower Records. Throw a single quote in the search page, it dumped SQL statements including tables, columns, and database names. Turns out the search function was vulnerable to TRUNCATE TABLE -- not that I ran it mind you:)
That doesn't even count the fact that the folks who handled the conversion of points to Flooz through their Java application forgot to check if you had the point you were converting in your account -- I converted 100,000 points ($1000) into real cash (well, real Flooz) from an account with 10 points in it.
No no, you're right. None of these problems are out there in the real world. Sure they aren't.
As people have pointed out in the various threads, folks get MS-SQL licenses for all sorts of things because they either already have a few licenses or because their consultants tell them they need them. Of course you need the MS-SQL license (or Oracle or Sybase or DB/2) for commercial ERP/CRM systems and some other hefty applications.
But what about decision support systems and (smaller) datawarehouses? Why should I license 4 processors of MS-SQL (e.g. 2 active, 2 for failover) for the DSS when I can get use MySQL? DSS/DW is mainly reading data -- stored procs, etc aren't that important, nor are transactions. Plus I can load MySQL with the batch update that is already using text files dumped out of the production MS-SQL server -- bcp on MS-SQL is a common way to load data. There's no good reason to drop another $40k on the reporting server.
I can even keep using Crystal Reports or ASP or whatever I'm already using. Plus I can run it on my existing Win2k servers (that's a strike against Postgres for now) without fighting over linux, etc.
Let's review MacBeth -- you know, Shakespeare. I'll just type in the ISBN and review it.... oh wait, Amazon has 104 books with different ISBNs. And that's just what's in print.
Cataloging books is hard -- that's why there are librarians. The real question is always about granularity. For example, do I want a review of the story of MacBeth? Am I interested in the quality of the footnotes? How about different editions of a scholarly version?
There's a lot of metadata you need to define to properly catalog a book. ISBNs are a start, but for all you OO folks (or Platonic idealists as well), the database needs the object BOOK of which we can define both instances and subclasses, etc.
Reviewing books is not as simple as it seems.
Of course once the data model's down, we can just thumbs up/down the book to make that part easy:)
If you're *co*locating servers with an ISP, you're entering a partnershiplike a lease. You're leasing space/power/bandwidth from them and promising to take care of things -- they promise to keep everything maintained. Both sides take risks and the risks are spelled out in the contract.
Every contract I've ever dealt with for a colo involves peak usage billing -- 95% percentile of average traffic is typical. Of course this is usually for a half rack, full rack, or cage -- not a single box. But that's been the deal at huge data centers (e.g. Exodus, RIP) and local ISPs(BNSI, my local colo provider).
They provide space, power, and bandwidth. I pay a flat rate for the space and power and a specified rate for the bandwidth -- my BNSI colo takes the higher of inbound or outbound 95% for the monthly charge.
I act as a good tenant -- I keep my boxes (even the windows ones) patched. I have a solid firewall. I put rate limiters on sites that need them. I monitor traffic. Everything a decent sysadmin does.
They act as a good landlord -- they keep things running, they notify me of problems, and they monitor their network well enough that I get a call when they notice (netsaint) my bandwidth spike, like when I upload 9 GB of data files for a client one evening.
We both act like responsible adults and everything is fine. Slammer's an excellent example -- one client at their site had an unpatched sql server -- sort of like letting the grass get 2 feet high in front of your rental house. The ISP cut them off, just like the landlord can step in and cut your grass if you're not maintaining it. Clients of mine at another site lost 6 hours of uptime because the ISP responded poorly to someone's unpatched box. Two days later, that ISP was hit by slammer on ANOTHER box. Not a good landlord -- they're not taking care of the properties they own.
A lot of the billing ideas in this discussion are intellectually sound but hard to implement in practivce -- I mean tracking each packet and throwing it in a particular category for billing? If the ISP is doing that, the costs are going to be $$$$ and those will be passed on. I don't want to pay that because I don't need it -- and the ISP shouldn't raise it's prices to solve a problem that's not really their problem.
So an incoming spike comes in -- I want a phone call/page where they ask me if that's OK. I'll even pay for the service. Whether it's a good (more business) or bad (hacker traffic) spike I need to react to it. I've got systems in place and they have systems in place. We're both good citizens. We both benefit. Max benefit for minimum work. I don't need to be charged properly for each packet -- I just need to be charged properly for my usage trends.
So write it into your contract -- don't use SQL Server, ask the ISP to block it outside your switch. Or keep the records yourself and contract with them to refund the bandwidth if you get excessive traffic you didn't and can't use. It's like saying "How about if I cut the grass and paint this rental house and you reimburse me the expenses if I do a professional job". Win/win for everyone. Clear terms. If I do a crappy painting job, I shouldn't get reimbursed, just like if I do a crappy record keeping job about packet traffic on the server I shouldn't get a refund.
Hacker attacks, etc, is part of the cost of doing biz on the Internet. You open a shop in real life, you deal with shoplifting -- you build it into your costs, either through higher security or anticipated "breakage" or whatever. I charge my clients more for SQL Server than MySQL not only because the license is much more expensive, but because the risks are higher from a security perspective. They'll be some breakage -- plenty of extra TCP 1433 on my firewall -- but it's built into the cost. As is the time I spend upgrading Windows 2000 and SQL Server. When you lease a house, you might call this normal wear and tear.
So it's a lease. Find a good landlord. Be a good tenant. Anticipate wear and tear. Build that into your budget.
Designing by vote isn't a bad idea at all. A number of comments I see on/. are to the tune of "If only (project X) had (feature y) it would be perfect". Or with M$-related postings, "If only (application X) didn't have (feature y) it would be better".
Let's say the Mandrake folks love Python and want it to install *instead* of Perl by default in their distro. That's fine -- it's there distro. But potentially if you ask the users you might find it's a different story about what they want.
Simple equation:
Many users = popular
Few users = unpopular
Note this doesn't mean good or bad, just popular. If the goal is more Linux and less Windows, popular is just as (if not more) important than technical merit.
Since you specifically mention ColdFusion as the development target, make sure you take a look at Fusedocs, a part of the Fusebox development methodology. Fusedocs are similar to Javadoc -- it is a way to self-document ColdFusion code in an XML format which can then be turned into more formal documentation.
You also owe it to yourself to check out Hal Helms website where he has tools for Fusedocs (including CF Studio VTML plugins) as well as the related wireframing and DevNotes tools -- both of which are extremely useful.
I've been doing CF for nearly 5 years and Fusebox, particularly the new Fusebox 3, is a useful design/development methodology as well as framework for building CF apps. Plus its all free/open-source/community-based/etc.
As a resident of Cville, I'd point out that tech *jobs* are far more important than what OS our fair city runs. And now that I think about it, open source means even fewer jobs in the municipal IT depts (*grin*)
Seriously Waldo, tech jobs are the technologically-focused issue. More jobs, more taxes. More jobs, lower unemployment. More jobs, better standard of living for the techies.
It seems to me that this company completely missed the point of how to integrate phones and the web -- which IMHO is to map the telephone number to the web site using the phone as a browser.
Emerging standards such as VoiceXML (and MS's own WTE "standard"), platforms such as WebSphere's Voice SDK, and service providers like Voxeo all make it easy to map a phone number to a URL using the telephone as the browser.
At the risk of being self-serving, my article on this went up today on oreillynet.com
http://www.oreillynet.com/pub/a/network/2000/11/28/voxeo.html
Bottom Line: Phone numbers are for dialing; web addresses are for surfing.
Slashdot Mirror
Wow, this isn't well thought out at all.
Javascript, more properly DHTML, is amazingly better than it was at the height of the browser wars. Compare Danny Goodman's DHTML Definitive Guide 1st and 2nd editions. The first one is all about how to handle the differences between Netscape and MS. The 2nd is all about documenting the *standard* DOM and how to script it. MUCH easier than it was 5 years (or 3 years) ago.
Java applets are slow -- no argument there, but hello? Sun? Java is controlled nearly as tightly as Flash. And if you read Macromedia's marketing, they're basically presenting Flash as the Visual Basic of the web. Love or hate VB, it certainly made it easier to build applications. Something similar for the web would have a similar effect -- increased ability for developers to write great apps and increasingly crappy code from non-developers who think they're developers since easy GUI tools lower the barrier to entry for development projects.
Abuse of the technology -- cookie abuse, popups, etc -- is not the fault of the browser. tech is tech, use is use.
And I'm no fan of Microsoft, but Internet Explorer is a *great* browser. Again, wind the clock back 5, or even 3 years. And 6.x is now the last of it's kind before MS rolls it back into the OS.
Exactly what Jakarta subprojects would you suggest for building an ERP system? Or CRM? Compiere? Please.
:)
I just spent 7 months with Epicor (ERP and CRM), which is one amazingly crappy piece of software. But where's the open source choice? I mean there's not even a viable OSS replacement for Quicken let alone a ERP, CRM, or real accounting system.
If you want tons of consulting bucks, write a *good* open source ERP or CRM platform and sell the consulting/support/training. But until there's a decent *enterprise* choice, we're stuck with the crap from the vendors.
One IT manager told me "All ERP solutions suck. And whichever one you choose sucks worst."
- Other software: software instruments, software effects processors, etc
- Other digital hardware: audio interfaces, midi interfaces, mLAN interfaces
- Other studio hardware: effects processors, mixers, etc, etc.
- microphones
- Instruments
- Musicians
Of course the discussion about record labels, etc is right on as far as why CDs cost so much, but my twofold point is: 1) ProTools has been making music cheaper/better for years 2) ProTools alone can't make a single sound -- you need plenty of other gearGood open source tools have 3rd party support, just like good closed source tools.
I can get Cisco/Oracle/MS/whatever corporate folks to support me directly or get an authorized partner to do the support. Open source projects that make headway in the enterprise either offer "vendor" support (eg MySQL AB, JBoss) through a consulting arm or through good grassroots 3rd party support that just pops up when the market can bear it.
The best way to knock over oracle is to start up a company that supports open source for a fee
MySQL AB does this already. Postgres has a similar but smaller plan in place. RedHat is another example in a non-db arena.
I see people using open source they can get support for -- it's that simple. JBoss is #3 depending on who you talk to. MySQL is gaining ground. Plenty of security tools are in the enterprise as well.
SQL injection *does* happen. I've seen it and plenty of web developers are not very SQL-savvy.
:)
Try these two phpnuke sql injection vulnerabilities (1,2) for example from this week's securityfocus.com vulnerability list. Those are just a couple from the open source world.
In early 2000, my dotcom would allow points to be redeemed for Flooz (remember them?) which could then be used at among other place, Tower Records. Throw a single quote in the search page, it dumped SQL statements including tables, columns, and database names. Turns out the search function was vulnerable to TRUNCATE TABLE -- not that I ran it mind you
That doesn't even count the fact that the folks who handled the conversion of points to Flooz through their Java application forgot to check if you had the point you were converting in your account -- I converted 100,000 points ($1000) into real cash (well, real Flooz) from an account with 10 points in it.
No no, you're right. None of these problems are out there in the real world. Sure they aren't.
As people have pointed out in the various threads, folks get MS-SQL licenses for all sorts of things because they either already have a few licenses or because their consultants tell them they need them. Of course you need the MS-SQL license (or Oracle or Sybase or DB/2) for commercial ERP/CRM systems and some other hefty applications.
But what about decision support systems and (smaller) datawarehouses? Why should I license 4 processors of MS-SQL (e.g. 2 active, 2 for failover) for the DSS when I can get use MySQL? DSS/DW is mainly reading data -- stored procs, etc aren't that important, nor are transactions. Plus I can load MySQL with the batch update that is already using text files dumped out of the production MS-SQL server -- bcp on MS-SQL is a common way to load data. There's no good reason to drop another $40k on the reporting server.
I can even keep using Crystal Reports or ASP or whatever I'm already using. Plus I can run it on my existing Win2k servers (that's a strike against Postgres for now) without fighting over linux, etc.
Let's review MacBeth -- you know, Shakespeare. I'll just type in the ISBN and review it.... oh wait, Amazon has 104 books with different ISBNs. And that's just what's in print.
:)
Cataloging books is hard -- that's why there are librarians. The real question is always about granularity. For example, do I want a review of the story of MacBeth? Am I interested in the quality of the footnotes? How about different editions of a scholarly version?
There's a lot of metadata you need to define to properly catalog a book. ISBNs are a start, but for all you OO folks (or Platonic idealists as well), the database needs the object BOOK of which we can define both instances and subclasses, etc.
Reviewing books is not as simple as it seems.
Of course once the data model's down, we can just thumbs up/down the book to make that part easy
If you're *co*locating servers with an ISP, you're entering a partnershiplike a lease. You're leasing space/power/bandwidth from them and promising to take care of things -- they promise to keep everything maintained. Both sides take risks and the risks are spelled out in the contract.
Every contract I've ever dealt with for a colo involves peak usage billing -- 95% percentile of average traffic is typical. Of course this is usually for a half rack, full rack, or cage -- not a single box. But that's been the deal at huge data centers (e.g. Exodus, RIP) and local ISPs(BNSI, my local colo provider).
They provide space, power, and bandwidth. I pay a flat rate for the space and power and a specified rate for the bandwidth -- my BNSI colo takes the higher of inbound or outbound 95% for the monthly charge.
I act as a good tenant -- I keep my boxes (even the windows ones) patched. I have a solid firewall. I put rate limiters on sites that need them. I monitor traffic. Everything a decent sysadmin does.
They act as a good landlord -- they keep things running, they notify me of problems, and they monitor their network well enough that I get a call when they notice (netsaint) my bandwidth spike, like when I upload 9 GB of data files for a client one evening.
We both act like responsible adults and everything is fine. Slammer's an excellent example -- one client at their site had an unpatched sql server -- sort of like letting the grass get 2 feet high in front of your rental house. The ISP cut them off, just like the landlord can step in and cut your grass if you're not maintaining it. Clients of mine at another site lost 6 hours of uptime because the ISP responded poorly to someone's unpatched box. Two days later, that ISP was hit by slammer on ANOTHER box. Not a good landlord -- they're not taking care of the properties they own.
A lot of the billing ideas in this discussion are intellectually sound but hard to implement in practivce -- I mean tracking each packet and throwing it in a particular category for billing? If the ISP is doing that, the costs are going to be $$$$ and those will be passed on. I don't want to pay that because I don't need it -- and the ISP shouldn't raise it's prices to solve a problem that's not really their problem.
So an incoming spike comes in -- I want a phone call/page where they ask me if that's OK. I'll even pay for the service. Whether it's a good (more business) or bad (hacker traffic) spike I need to react to it. I've got systems in place and they have systems in place. We're both good citizens. We both benefit. Max benefit for minimum work. I don't need to be charged properly for each packet -- I just need to be charged properly for my usage trends.
So write it into your contract -- don't use SQL Server, ask the ISP to block it outside your switch. Or keep the records yourself and contract with them to refund the bandwidth if you get excessive traffic you didn't and can't use. It's like saying "How about if I cut the grass and paint this rental house and you reimburse me the expenses if I do a professional job". Win/win for everyone. Clear terms. If I do a crappy painting job, I shouldn't get reimbursed, just like if I do a crappy record keeping job about packet traffic on the server I shouldn't get a refund.
Hacker attacks, etc, is part of the cost of doing biz on the Internet. You open a shop in real life, you deal with shoplifting -- you build it into your costs, either through higher security or anticipated "breakage" or whatever. I charge my clients more for SQL Server than MySQL not only because the license is much more expensive, but because the risks are higher from a security perspective. They'll be some breakage -- plenty of extra TCP 1433 on my firewall -- but it's built into the cost. As is the time I spend upgrading Windows 2000 and SQL Server. When you lease a house, you might call this normal wear and tear.
So it's a lease. Find a good landlord. Be a good tenant. Anticipate wear and tear. Build that into your budget.
Designing by vote isn't a bad idea at all. A number of comments I see on /. are to the tune of "If only (project X) had (feature y) it would be perfect". Or with M$-related postings, "If only (application X) didn't have (feature y) it would be better".
Let's say the Mandrake folks love Python and want it to install *instead* of Perl by default in their distro. That's fine -- it's there distro. But potentially if you ask the users you might find it's a different story about what they want.
Simple equation:
Many users = popular
Few users = unpopular
Note this doesn't mean good or bad, just popular. If the goal is more Linux and less Windows, popular is just as (if not more) important than technical merit.
Since you specifically mention ColdFusion as the development target, make sure you take a look at Fusedocs, a part of the Fusebox development methodology. Fusedocs are similar to Javadoc -- it is a way to self-document ColdFusion code in an XML format which can then be turned into more formal documentation.
You also owe it to yourself to check out Hal Helms website where he has tools for Fusedocs (including CF Studio VTML plugins) as well as the related wireframing and DevNotes tools -- both of which are extremely useful.
I've been doing CF for nearly 5 years and Fusebox, particularly the new Fusebox 3, is a useful design/development methodology as well as framework for building CF apps. Plus its all free/open-source/community-based/etc.
As a resident of Cville, I'd point out that tech *jobs* are far more important than what OS our fair city runs. And now that I think about it, open source means even fewer jobs in the municipal IT depts (*grin*)
Seriously Waldo, tech jobs are the technologically-focused issue. More jobs, more taxes. More jobs, lower unemployment. More jobs, better standard of living for the techies.
It seems to me that this company completely missed the point of how to integrate phones and the web -- which IMHO is to map the telephone number to the web site using the phone as a browser. Emerging standards such as VoiceXML (and MS's own WTE "standard"), platforms such as WebSphere's Voice SDK, and service providers like Voxeo all make it easy to map a phone number to a URL using the telephone as the browser. At the risk of being self-serving, my article on this went up today on oreillynet.com http://www.oreillynet.com/pub/a/network/2000/11/28 /voxeo.html
Bottom Line: Phone numbers are for dialing; web addresses are for surfing.