Domain: covalent.net
Stories and comments across the archive that link to covalent.net.
Comments · 16
-
Re:Who cares?
Somehow, DOUBLECLICK is the biggest concern? Not a chance. This is media hype perpetuated by the competition crying foul. I really wish people would concern themselves with actual privacy issues. It's just advertising data, people.
Ti you it make seem like just advertising data, but it qualifies as stalking in Texas.
It's interesting that Homeland Security looked to someone from doubleclick to protect personal privacy.
It's kinda funny how marketing-speak changed the name "web bugs" to the almost religiously enlightened sounding "web beacons" that help track what you've read, and through your IP, where. They say you can opt out. That sets a cookie!
Web bugs can be in email, web pages, even some documents.
The combination of web bugs and other techniques can still mine considerable data even with cookies off or frequently deleted.
I generally have liked Google, but it seems this is not the only instance of them connecting with slime. -
Covalent
Check out Covalent in San Francisco.
Apache is what they do. Several of the major Apache developers work for Covalent. The company provides training, support and managed services for Apache, Tomcat, etc.
-
Re:What she really said
It has managed to do this with little commercial support
But not zero. And the commercial support is two-fold:
- development of the Apache code base,
- installation, customization and maintenance for users.
Sure, customers love high performing, reliable, more secure software such as Apache. And, if they have someone with some expertise with a few hours to spare once in a while, then they can maintain their own web sites cost effectively without ever cutting a check to anyone outside the company. And the effort required to support Apache may be lower than the competition in many situations. But it's still not zero. While the company can download and run Apache without ever contributing any code tot he project, code still had to be written and still needs to be maintained.
The Apache Foundation includes members of several commercial concerns. That commercial support of the open source project has probably helped immeasureably in making Apache better.
Also, for businesses and other users that would like to contract out Apache support there are vendors (eg, Covalent, IBM, HP, Red Hat, Novell/SuSE,
...) that will provide it. -
Re:this is killing Linux, OSD in general
Covalent provides support and services for Apache, and many customers can be referenced.
-
Re:Making a return
SleepyCat (Berkely DB)
Zope Corporation (Zope)
Covalent Technologies (Apache)
ActiveState
I deliberately haven't included Apple for reasons cited above, but Apple is almost as much a software company as it is a hardware company.
-
Shameless plug ...
-
Re:Complaints Timescale
- Seriously, though, it's a pretty impressive turn around time and should give some credence to those of us making arguments that the support is really there for open source projects like Apache, even though there's no "1-800-HELPME" number nor an expensive maintenance and support agreement.
You can have your maintenance and support agreement, complete with 24x7 support line, if that's what you need, by contracting with someone like Covalent. Covalent will be providing those patches pretty soon for their releases, it seems.
-
Comanche!
Comanche anyone? I remember using this tool to configure my Apache boxen long ago. I since got used to editing
.conf files in vi. Still, the article makes mention that there's no GUI. I beg to differ! I don't know if it supports Apache 2.0 yet, but there's a windows binary for 1.3. Just wait, and the GUI will come. -
Re:So Lets SeeNot only that, but you can trade:
- Free
For:
- "All configuration and administration is done by editing
.conf files
If you buy the product your Apache from Covalent. They offer all kinds of Enterprise services to support Apache, too, so there goes the one about Apache not having a support organization behind it like IIS.
-
Re:The real reason most companies don't use it...
That about sums it up. Most corporations are not in the software business; they have IT staff, but not programming and development staff....just guys that maintain and secure the servers and networks.
Most corporations are not in the car business, still I prefer to have a choice who can fix my car. You know how expensive are even the simplest things in brand authorized car service companies, now only imagine how much more expensive would it be if you were not even allowed to fix your car anywhere else.
These guys aren't going to desk-check all the code for buffer overflows and the like, they just want to install it, configure it, and apply security patches that the software developers wrote.
That's funny, because that's exactly what I do with my Debian boxes. Well, almost. I install them, configure, and I don't apply security patches, I just run apt-get upgrade.
Don't fool yourself, you don't have to check for buffer overflows when you use Debian and you don't have to check for buffer overflows when you use Windows (well, you can't anyway, so let's just say you don't have to). The difference is when you want to customize the software.
To customize IIS you have to hire Microsoft (good luck with that). To customize Apache you can hire someone from The Apache Software Foundation, you can hire someone from Apache Support Webring, you can hire someone from Covalent Technologies, Red Hat, Thawte, Dana Point Communications, or you can hire me - as we all have the source, we all know the internal API and we all have a right to customize Apache.
You can even use one of your guys that maintain and secure the servers and networks if the customizations you need are easy enough. Remember how Apache httpd internals are deigned. The most fancy customization is usually just a simple mod_perl module.
The same is with ASP versus Perl, MS-SQL versus MySQL, MSVC++ versus GCC, et cetera. Using free software is smarter from the business standpoint than using proprietary software, it's only the transition that's difficult, once you've got into the mess of proprietary file formats, protocols and "standards".
-
Covalent and Apache
While I agree with the author that it's hard to sell an Open Source only project, I'm really curious to see how Covalent does selling Apache web server management systems. They take a good open source engine and add something of value, a good user interface for doing complicated tasks, to it before selling it. Perhaps that's a better business model than trying to sell GPL'ed software directly?
-
Re:Quality Config Tools
-
The Apache Public License
Maybe it would be good to add the APL which I think is close to a BSD style license.
BTW, to have an idea about what APL developpers think about GPL (LPGL in fact) just have look here it's an excerpt from a discussion where the integration of GNU Regexp was seriouly discussed in cocoon-dev mailing list. -
Re:Upgrading from 1.3.x & preserving configuration
Whaddya mean, Apache doesn't run on a tea kettle?
This is absolutely hilarious. If it actually runs Apache I'm going to have to get one for the office.
Otherwise, the most exotic things we're doing seem to be Raven (which you make sound like it isn't very exotic at all) and NetSaint, which I can handle just fine.
Raven is an SSL plugin. I work for the company that makes it (but I don't speak for them, #include stddisclaimer.h), so that's probably why it's not very exotic to me. Raven is a closed source module. Otherwise, if you have the source code of your current version, you can do a diff against the present code base to see what the differences are. If you're really in the dark, you should approach the web server like a black box and (re)define a set of functional requirements, collect and integrate the software and keep record of what you have been doing on file. That's a sound business practice anyway: what if your present webserver irrepairably crashes?
Oh, have you considered making soft links for the most frequently occuring 404's with the misspel(l)ed names? This may be a bit more maintenance intensive but you don't need mod_speling.
-
Re:Suggestions - SSL WebserversActually, instead of StrongHold, I think Raven SSL for Apache would be better way to go. It's $357 vs $995 for Stronghold. Covalent (the company who sells Raven SSL) also does technical support for both the Raven SSL module and Apache in general, which should go over well with the suits.
You can find its website here: http://www.covalent.net/
Or if you live in a free country, you can use mod_ssl at http://www.modssl.org
Also, I wouldn't really call it a close race between Postgres and MySQL features. MySQL doesn't plan to do SQL Transactions, for instance, while Postgres does. MySQL, on the other hand, has much friendlier SQL extensions, particularly for date formatting and such. Both have commercial support options.
-
raven
A year and a half ago I spent some time researching the least expensive licensing for SSL with Apache for a webserver running approximately 80-128 sites, and it came out that at that time, for that setup that Raven "/A> was the best option. This may well have changed, as it looks like they've raised their prices, and it depends largely on how many customers you have, because of licensing fees and such. It's probably worth a look, though.