Good answer, but I don't think that was the question.. Given that http/html already exists, how would asn.1 improve it today? What I meant was that straightforward, stupid, lossless compression is a better solution for today's http/html bandwidth problems than obfuscating html.
The whole point of HTML (and XML) is readability. It is nigh-pointless to invent an ascii-based protocol and then cut it down such that even fluent experts need a special tool to work with it. If that was your goal then you should have used a binary protocol from the start. If you could travel back in time would you have implored the w3c to make the html spec as terse as possible to save on overhead? After all, think of all the countless bytes that "" notation wastes!
Why don't we just program everything in assembly while we're at it? Would you say that assembly is the 'best' solution for limited CPU power? Certainly not. There's a place for this kind of penny-wise pound-foolish behavior, but it's certainly not generalizable.
Holding up Google as a proof of your argument that unreadable HTML is a superior solution doesn't mean anything, for obvious reasons. It's interesting to see that they have chosen that tactic the meet their particular set of needs, but that's as far as it goes. I wouldn't be surprised if google's internal HMTL is more readable, but is "compiled" down into a sparse unreadable block for production use. Do you think this added step is worthwhile for most people?
The best compromise is still compression. A fast compression algorithm like LZO (or even gzip) can reduce bandwidth even more than twinking out your variable names and spaces AND still provides readability.
Excellent question. The answer to the backup problem is probably going to be (for those of us without an array of LTO drives) a USB 2.0 or Firewire enclosure around another 320MB drive!
Another possible option might be a hot-swappable, removable IDE drive bay. 3ware, still alive and kicking, makes them and the controllers to go with. Maybe even serial ATA will be an option soon.
Perhaps we'll see cheap hard drive carrying and storage cases catch on soon, or just differently specced drives specifically geared for archival purposes. Possibly they will have lower performance, but be more reliable and shock resistant?
Just an idea to throw out there for the low-budget crowd who likes random-access devices.
The main difference is that we sell a "turn-key solution". It's a black box destined to go straight to end users who don't interact with the OS directly and in 99% of cases don't want to even know whether Linux is under the hood or Windows, or Solaris, etc, so long as box does what it is supposed to do. Of course a super power user could get into the OS and run other applications and scripts- unlike some other vendors we make it relatively easy to do that.
We provide a customized kernel that includes the most up to date drivers for the periphrials the box needs to talk with, some of which are esoteric. We also do some performance tuning and add some publicly available security patches.
I believe what we do is fundamentally different from what Rational does. We're selling a black box solution that solves one particularly complex problem. That's what our customers want, and there is no expectation that the customer will be able to run other applications on the platform, never mind use a different kernel. The product includes hardware and software maintenance that keeps the system up to date and secure, so it's important for maintenance purposes that we keep the system configuration under tight control.
Rational sells a software development tool. The expectation is that the end user will be running the client on the development system, which presupposes a wide variety of both hardware and software, depending on whatever the customer wants to develop. When rational ties their product to a small subset of Linux kernels, they dramatically limit what kinds of development you can do, which is not a particularly competitive thing to do. Worse, their supported kernels do not keep pace with security patches or major driver bugs (like the ext3 bug in redhat's initial 7.3 kernel release).
Sorry to have ranted a little off subject to your original question.
One thing you might try is switching your build machines to use snapshot views. This reduces the network overhead and allows for more disconnected style of operation. It's a huge win for compile-farms where you only want to pull recent files and rarely if ever commit changes back. Doing this may solve your reliability issues as well speed up compiles.
Clearcase is returning files slowly? I don't believe it!
No personal offense intended. We've wrestled with the same problems ourselves and have ultimately decided to look at alternatives to clearcase.
There's a couple big problems. The biggest one is that clearcase requires you to use a modified linux kernel, and they only provide stable modifications for a handful of older, stale kernels. If you want to keep up with security updates, you are on your own. If you want to update to a newer kernel that solves some device driver problem, forget it. If your product depends on you using a custom kernel like ours does, you are totally screwed. Unless rational finds some way to make their product work without requiring specific kernel versions, it will never be a good fit with Linux. Your stability problems may be caused by not using a Rational-approved kernel.
The second huge problem with clearcase is not linux specific- it has to do with clearcase's architecture. Clearcase requires each client to use a proprietary NFS-like filesystem (MVFS) in order to interface nicely with the server. MVFS has a very high overhead both in terms of network traffic and server CPU time. It has poor security, poor performance, and poor reliability. Even on solaris it's ugly, and on rational's second tier systems such as Linux and Irix it's even worse. Imagine trying to maintain an entire closed-source network filesystem codebase just for one application. That's the problem that clearcase's development team faces, and I guess I can't fault them for not doing it well.
Clearcase's architecture realistically limits your clients to being on the same local network with a persistent, always-on connection. In addition, the server needs to be a very expensive top-end solaris box. Also, if you want to support remote development you either have to wrestle with the unfriendly, unpolished "snapshot views" configuration or shell out huge dollars for a multisite license and a dedicated person to support it.
If you are misfortunate enough to be stuck with an older or poorly performing network clearcase can be unusable. You absolutely must have high bandwidth, low latency paths between your clearcase server, build platforms, and clients. It sounds offhand like this may be your problem. Put in a direct (no hops) 100bT line between a linux client and the clearcase server, make sure the clearcase server isn't under heavy load from other people, and rerun your tests.
Rational encourages you to use clearcase to manage your entire build operation, and version binaries and object files as well as source. This does has some benefits, but it makes already bad performance become downright abyssal and makes it very difficult to switch products once you realize Clearcase is no longer the right fit for your organization.
Finally, Rational appears to be completely ignoring these shortcomings with clearcase on Unix. Over the last couple years they have ported Clearcase to Windows and rewritten all of the administration tools. However, the second-generation admin tools are WINDOWS ONLY. If you want to use tools that don't suck, you need a Windows box. I find it incredulous that rational had a cross-platform product, and when they had the opportunity to make cross platform tools using any number of high quality cross-platform libraries, they chose to go with one platform only. I've asked when the next generation tools will be ported back to Unix/Linux, and they have no plans to do that. I love the command line as much as any card-carrying unix geek, but I demand the best tools for the job. I don't like being on rational's second-class platform.
To me, this underscores the fact that sales and marketing are running the show over at Rational. Rational aquires products so they can lock in customers, and then they scale back development and move on to the next product. Unfortunately people using clearcase on unix have invested so much time integrating clearcase into their workflow that the costs of changing to a different SCM platform are unbearable. Yet, if you look around, you will find competitors like Perforce and BitKeeper offering better products at orders of magnitude less license/maintenance fees. These competing products scale better, can be used over the internet easily, don't require a custom kernel (!!!), and require substantially less dedicated support staff to maintain.
Shop around. Moving to Linux might be a good time to use something that works better and costs less than maintaining clearcase, even in the short term.
Our AS400 systems were very impressive-looking in a "I AM BORG" type way. They had great reliability and service, but they were older models, expensive to maintain, and didn't have very good performance. I suspect other shops are in the same boat.
We started using Linux machines as development platforms. The AS400 guys could run db2 and other IBM technologies on Linux, which was a big win. The development stations were dirt cheap and for many jobs faster than the AS400.
Eventually as that department became more comfortable with Linux they stopped placing every business application on the AS400s if a properly configured Intel/Linux box could do a cheaper/faster job without unacceptable risk exposure. It turned out quite a few applications fell into that category.
The key is to have someone who has a deep understanding of linux and also can talk to the hardcore "mainframe" admins. There is definitely a culture shock to overcome. Imagine trying to explain Linux to someone who calls service for any task that might require opening a box, pays 10k/year license fees for a glorified tar backup system, and knows so many esoteric commands and proprietary-os arcana to make VAX and UNIX together look like kiddie toys.:)
I hope it has fun monitoring my SSHv2 connections. Traffic analysis is fine with me. Eavesdropping on plaintext conversations is not.
Everyone should use good encryption! The EFF should start a fund to develop easy to use encryption infrastructure for the masses.
Needed:
FTP clients that transparently use SFTP whenever possible, and warn the user when their session is unencrypted.
Seamless plugins to mozilla-mail and other popular standalone and web-based email clients to allow for easy key-exchange, signing, and encryption. Ideally the email client would automatically encrypt whenever it had the recipient's public key, and there was an automated mechanism to retrieve that key via an email attachment. Likewise, the client would automatically sent out attachments with your public key to all your recipients along with your normal email so others could use them.
Encrypted IM. Jabber, please save us. IM clients should be written to prefer jabber servers over "all your conversation are belong to us" style servers such as AIM and MSM.
FreeNet. Take however long it is necessary to do the right thing. Just don't give up. We need you.
- Factsheets of functionality, both abbreviated and full technical detail. Nothing bothers me more than marketing documentation that leaves out important technical information. If I have to call up a salesperson to find out if it will work on platform (x) I won't call.
- Downloadable demo. Preferrably without requiring pages of personal information. Asking for personal info in exchange for demo software is a big turn off. If I like the product, I'll be in touch. I *always* fill out the registration/personal info pages with completely bogus information anyway. Please get rid of these things.
- Online documentation with the following:
Usage documentation w/ examples
API documentation w/ examples
- Case studies on how the product contributed to various solutions are helpful, so long as they are written in everyday english. I hate case studies that are full of buzzwords and glittering generalities that don't say a damn thing about what actually happened.
- Online community support system/knowledgebase, either via newsgroup, mailing list, webpage, etc. This basic level of support should be free. Charging extra for access to upper-tier experts is fine.
- For getting the word out, listings on freshmeat/sourceforge and other industry directories are a good start. Presence at trade shows helps. Trade magazine reviews help. Reputable third-party books help once you're that mature. Taking out ads on slashdot probably helps too:)
The general rule of thumb is to treat me as an educated consumer and provide truthful information resources so *I* can make that decision. If I feel like the marketing department is trying to hide the product behind buzzword literature so that I have to talk to a salesperson in order to find out anything meaningful, I'll won't be calling. I don't mind calling to ask specific questions or clarify a specific point, but all the basic information describing the product should be readily available.
As cool as the SGI FUEL system looks on paper, and as cool as the case looks in person, it provides poor value.
We've successfully ported our high end graphics/ video application from the SGI platform to Linux running on a high end dual-xeon workstation.
The Linux/Intel performance is more than double that of the fuel system, and our apps push the system to its limits. And, even figuring in the cost of the high end video boards, the Linux/Intel solution is 1/4 of the FUEL price.
In most cases I would agree with you. I generally ignore extended warranties on small ticket items at a department store or an elecontrics shop out of hand, because I know that they are generally poor value propositions.
However, the specific case of the applecare extended tech support/full hardware warranty on an iBook is different.
A laptop *is* likely to break at some point over a three-year span either from mechanical failure or (more likely) by human accident, especially if you are in a college environment. The minimum cost for a iBook repair is about $350, and the average cost is significantly higher. If you manage to damage your display screen, you might as well write the whole unit off.
250$ for the extra 2 years of no-questions-asked tech support is exactly what you want if you're a college student. Do you really think your laptop is going to make it through college in one piece?
As a comparison, try checking the prices of in-store maintenance contracts for the same hardware. You'll find Apple is more than reasonable.
On the flip side, consider that any hardware repair at all after the first year will run you at least 350$ for parts and labor. You're foolish not the get the applecare warranty.
Remember that apple systems have a longer lifetime than typical PC counterparts. You're going to be using that ibook for a long time to come, you might as well take care of it.
Replying to my own post with extra information for the benchmark-interested..
The benchmarks were performed with IOzone on top of an ext3 file system. Write caching for the IDE drive was DISABLED, which adds latency to write calls and is somewhat responsible for the lower scores.
I've learned the hard way that leaving the write caching on (the default setting!) on an IDE drive can hose even a journaled filesystem during a system hang or sudden power loss event. Does anyone know if there is any way around this problem, other than disabling write caching?
I've benchmarked our various disk subsystems heavily.
Once you get exhaust the on-disk cache and the filesystem cache, the raw disk access speeds are visible. Here's what I've found for Seagate ATA-IV 80MB drives:
That was benchmarked on a 2Gz dual Xeon system under linux with nothing else running, and IDE tuned optimally. So, real life results are going to be worse.
It would not surprise me to see most consumer level systems with sustained speeds on a single disk under 10MB/sec. Most systems that use IDE drives don't have the DMA/ATA mode settings tuned aggressively.
Most systems with RAIDs have crappy implementations. Get a hardware RAID controller with its own processor and a large-bandwidth backend bus (ie, SCSI-160 or higher) and with lots of onboard battery-backed memory so you can safely turn on write caching.
I would respectfully disagree with your position on reselling "RedHat Linux". You can distribute Linux any way you want as permitted by the GPL, but RedHat has a right to their trademark. You have to call your distribution something other than RedHat. Only RedHat has the right to use the RedHat trademark.
This isn't "making life difficult", it's the way business is done. You make yourself look like an ass when you attack RedHat for requesting that you respect their trademark.
There are many different legal mechanisms one can use to control distribution of software.. Off the top of my head, I know of:
Copyright Patents ShrinkWrap Licenses Technical Means (DMCA in the USA)
I personally disagree with the implementation of most the above. Copyright terms are too long, Patents are given out frivolously for types of things I personally don't believe should be patentable (business methods, software, algorithms), Shrinkwrap licenses are a one-sided travesty of a contract, and represent a blatant effort to avoid consumer protections based on ownership, and the DMCA is just an unjust pile of total crap.
Of the above, copyright is the least objectionable distribution control device. Therefore, I prefer licenses that rely soley on copyright rather than one of the other means.
I would be very much put off by a license that enforced the use of a click-through agreement. I dearly hope OSI and the FSF reject such things.
Am I the only one who thinks that upstream caps are a bad idea?
I don't want a 3Mb/328kb asymterical connection.. but I'd easily pay 80$ for 1.5Mb symmetrical. What is the problem here? Why do I get the feeling one of the big reasons an upstream cap exists is to create an artificial scarcity of servers? What does the telco care what I use my bits for, so long as I am paying?
Slightly off topic, but the apache project's log4j is the most elegent evolution of the "printk" school of debugging I have seen to date.
You can log against any backend source you feel like, flat files, syslog, databases, etc. You can remove the logging module entirely at runtime, without paying a performance hit for the debug statements. This saves a lot of jumping back and forth when you're trying to package up a release. If you're stuck without the fund$ for a top-end debugger it's the next best thing. It's for java, but I don't see any reason why the concept couldn't be ported to C++.
Looking at the data, it looks the two samples where Ogg performed poorly ended up being encoded at a significantly smaller average bitrate than any of the other encoders.
The table at the end lists LiszBMinor with an average ogg bitrate of 45 and BachS1007 with an average bitrate of 47. Since the other codecs encoded those samples at a bitrate 64 or higher, this may explain the results.
The results may point to a flaw in Ogg's VBR login rather than in the lossy compression scheme.
I agree with the observation that SiS has been an unexpected dark horse mobo/chipset candidate lately.
One correction though: Last I heard it was not a proven fact that Via doesn't have a "valid" P4 license. Via claims that the license is valid because they purchased S3, and S3 had a license. Intel claims S3's license was not transferrable. It seems the case is still up the in air, and the lawyers will have to sort it out. Via does seem to have a reasonable claim to the license, however.
Slashdot Mirror
Good answer, but I don't think that was the question.. Given that http/html already exists, how would asn.1 improve it today? What I meant was that straightforward, stupid, lossless compression is a better solution for today's http/html bandwidth problems than obfuscating html.
I can't believe people mod this stuff up..
The whole point of HTML (and XML) is readability. It is nigh-pointless to invent an ascii-based protocol and then cut it down such that even fluent experts need a special tool to work with it. If that was your goal then you should have used a binary protocol from the start. If you could travel back in time would you have implored the w3c to make the html spec as terse as possible to save on overhead? After all, think of all the countless bytes that "" notation wastes!
Why don't we just program everything in assembly while we're at it? Would you say that assembly is the 'best' solution for limited CPU power? Certainly not. There's a place for this kind of penny-wise pound-foolish behavior, but it's certainly not generalizable.
Holding up Google as a proof of your argument that unreadable HTML is a superior solution doesn't mean anything, for obvious reasons. It's interesting to see that they have chosen that tactic the meet their particular set of needs, but that's as far as it goes. I wouldn't be surprised if google's internal HMTL is more readable, but is "compiled" down into a sparse unreadable block for production use. Do you think this added step is worthwhile for most people?
The best compromise is still compression. A fast compression algorithm like LZO (or even gzip) can reduce bandwidth even more than twinking out your variable names and spaces AND still provides readability.
Text compresses really well. It's pretty foolish to sacrifice maintainability of your page code to save bits. There are better solutions.
The simplest way to combat this misperception is to tell someone how much more they would have payed for a comparable performance Intel chip.
Excellent question. The answer to the backup problem is probably going to be (for those of us without an array of LTO drives) a USB 2.0 or Firewire enclosure around another 320MB drive!
Another possible option might be a hot-swappable, removable IDE drive bay. 3ware, still alive and kicking, makes them and the controllers to go with. Maybe even serial ATA will be an option soon.
Perhaps we'll see cheap hard drive carrying and storage cases catch on soon, or just differently specced drives specifically geared for archival purposes. Possibly they will have lower performance, but be more reliable and shock resistant?
Just an idea to throw out there for the low-budget crowd who likes random-access devices.
FYI, I've had great luck with my dual athlon tyan board. It's going on 9 months uptime. So, there's choices out there if you want to look around.
Most electronics do have a smell when you first begin using them. The smell usually goes away after a week or so.
The main difference is that we sell a "turn-key solution". It's a black box destined to go straight to end users who don't interact with the OS directly and in 99% of cases don't want to even know whether Linux is under the hood or Windows, or Solaris, etc, so long as box does what it is supposed to do. Of course a super power user could get into the OS and run other applications and scripts- unlike some other vendors we make it relatively easy to do that.
We provide a customized kernel that includes the most up to date drivers for the periphrials the box needs to talk with, some of which are esoteric. We also do some performance tuning and add some publicly available security patches.
I believe what we do is fundamentally different from what Rational does. We're selling a black box solution that solves one particularly complex problem. That's what our customers want, and there is no expectation that the customer will be able to run other applications on the platform, never mind use a different kernel. The product includes hardware and software maintenance that keeps the system up to date and secure, so it's important for maintenance purposes that we keep the system configuration under tight control.
Rational sells a software development tool. The expectation is that the end user will be running the client on the development system, which presupposes a wide variety of both hardware and software, depending on whatever the customer wants to develop. When rational ties their product to a small subset of Linux kernels, they dramatically limit what kinds of development you can do, which is not a particularly competitive thing to do. Worse, their supported kernels do not keep pace with security patches or major driver bugs (like the ext3 bug in redhat's initial 7.3 kernel release).
Hope that clears it up..
Sorry to have ranted a little off subject to your original question.
One thing you might try is switching your build machines to use snapshot views. This reduces the network overhead and allows for more disconnected style of operation. It's a huge win for compile-farms where you only want to pull recent files and rarely if ever commit changes back. Doing this may solve your reliability issues as well speed up compiles.
Clearcase is returning files slowly? I don't believe it!
No personal offense intended. We've wrestled with the same problems ourselves and have ultimately decided to look at alternatives to clearcase.
There's a couple big problems. The biggest one is that clearcase requires you to use a modified linux kernel, and they only provide stable modifications for a handful of older, stale kernels. If you want to keep up with security updates, you are on your own. If you want to update to a newer kernel that solves some device driver problem, forget it. If your product depends on you using a custom kernel like ours does, you are totally screwed. Unless rational finds some way to make their product work without requiring specific kernel versions, it will never be a good fit with Linux. Your stability problems may be caused by not using a Rational-approved kernel.
The second huge problem with clearcase is not linux specific- it has to do with clearcase's architecture. Clearcase requires each client to use a proprietary NFS-like filesystem (MVFS) in order to interface nicely with the server. MVFS has a very high overhead both in terms of network traffic and server CPU time. It has poor security, poor performance, and poor reliability. Even on solaris it's ugly, and on rational's second tier systems such as Linux and Irix it's even worse. Imagine trying to maintain an entire closed-source network filesystem codebase just for one application. That's the problem that clearcase's development team faces, and I guess I can't fault them for not doing it well.
Clearcase's architecture realistically limits your clients to being on the same local network with a persistent, always-on connection. In addition, the server needs to be a very expensive top-end solaris box. Also, if you want to support remote development you either have to wrestle with the unfriendly, unpolished "snapshot views" configuration or shell out huge dollars for a multisite license and a dedicated person to support it.
If you are misfortunate enough to be stuck with an older or poorly performing network clearcase can be unusable. You absolutely must have high bandwidth, low latency paths between your clearcase server, build platforms, and clients. It sounds offhand like this may be your problem. Put in a direct (no hops) 100bT line between a linux client and the clearcase server, make sure the clearcase server isn't under heavy load from other people, and rerun your tests.
Rational encourages you to use clearcase to manage your entire build operation, and version binaries and object files as well as source. This does has some benefits, but it makes already bad performance become downright abyssal and makes it very difficult to switch products once you realize Clearcase is no longer the right fit for your organization.
Finally, Rational appears to be completely ignoring these shortcomings with clearcase on Unix. Over the last couple years they have ported Clearcase to Windows and rewritten all of the administration tools. However, the second-generation admin tools are WINDOWS ONLY. If you want to use tools that don't suck, you need a Windows box. I find it incredulous that rational had a cross-platform product, and when they had the opportunity to make cross platform tools using any number of high quality cross-platform libraries, they chose to go with one platform only. I've asked when the next generation tools will be ported back to Unix/Linux, and they have no plans to do that. I love the command line as much as any card-carrying unix geek, but I demand the best tools for the job. I don't like being on rational's second-class platform.
To me, this underscores the fact that sales and marketing are running the show over at Rational. Rational aquires products so they can lock in customers, and then they scale back development and move on to the next product. Unfortunately people using clearcase on unix have invested so much time integrating clearcase into their workflow that the costs of changing to a different SCM platform are unbearable. Yet, if you look around, you will find competitors like Perforce and BitKeeper offering better products at orders of magnitude less license/maintenance fees. These competing products scale better, can be used over the internet easily, don't require a custom kernel (!!!), and require substantially less dedicated support staff to maintain.
Shop around. Moving to Linux might be a good time to use something that works better and costs less than maintaining clearcase, even in the short term.
Our AS400 systems were very impressive-looking in a "I AM BORG" type way. They had great reliability and service, but they were older models, expensive to maintain, and didn't have very good performance. I suspect other shops are in the same boat.
:)
We started using Linux machines as development platforms. The AS400 guys could run db2 and other IBM technologies on Linux, which was a big win. The development stations were dirt cheap and for many jobs faster than the AS400.
Eventually as that department became more comfortable with Linux they stopped placing every business application on the AS400s if a properly configured Intel/Linux box could do a cheaper/faster job without unacceptable risk exposure. It turned out quite a few applications fell into that category.
The key is to have someone who has a deep understanding of linux and also can talk to the hardcore "mainframe" admins. There is definitely a culture shock to overcome. Imagine trying to explain Linux to someone who calls service for any task that might require opening a box, pays 10k/year license fees for a glorified tar backup system, and knows so many esoteric commands and proprietary-os arcana to make VAX and UNIX together look like kiddie toys.
I hope it has fun monitoring my SSHv2 connections. Traffic analysis is fine with me. Eavesdropping on plaintext conversations is not.
Everyone should use good encryption! The EFF should start a fund to develop easy to use encryption infrastructure for the masses.
Needed:
FTP clients that transparently use SFTP whenever possible, and warn the user when their session is unencrypted.
Seamless plugins to mozilla-mail and other popular standalone and web-based email clients to allow for easy key-exchange, signing, and encryption. Ideally the email client would automatically encrypt whenever it had the recipient's public key, and there was an automated mechanism to retrieve that key via an email attachment. Likewise, the client would automatically sent out attachments with your public key to all your recipients along with your normal email so others could use them.
Encrypted IM. Jabber, please save us. IM clients should be written to prefer jabber servers over "all your conversation are belong to us" style servers such as AIM and MSM.
FreeNet. Take however long it is necessary to do the right thing. Just don't give up. We need you.
Here's what I look for when evaluating tools:
:)
- Factsheets of functionality, both abbreviated and full technical detail. Nothing bothers me more than marketing documentation that leaves out important technical information. If I have to call up a salesperson to find out if it will work on platform (x) I won't call.
- Downloadable demo. Preferrably without requiring pages of personal information. Asking for personal info in exchange for demo software is a big turn off. If I like the product, I'll be in touch. I *always* fill out the registration/personal info pages with completely bogus information anyway. Please get rid of these things.
- Online documentation with the following:
Usage documentation w/ examples
API documentation w/ examples
- Case studies on how the product contributed to various solutions are helpful, so long as they are written in everyday english. I hate case studies that are full of buzzwords and glittering generalities that don't say a damn thing about what actually happened.
- Online community support system/knowledgebase, either via newsgroup, mailing list, webpage, etc. This basic level of support should be free. Charging extra for access to upper-tier experts is fine.
- For getting the word out, listings on freshmeat/sourceforge and other industry directories are a good start. Presence at trade shows helps. Trade magazine reviews help. Reputable third-party books help once you're that mature. Taking out ads on slashdot probably helps too
The general rule of thumb is to treat me as an educated consumer and provide truthful information resources so *I* can make that decision. If I feel like the marketing department is trying to hide the product behind buzzword literature so that I have to talk to a salesperson in order to find out anything meaningful, I'll won't be calling. I don't mind calling to ask specific questions or clarify a specific point, but all the basic information describing the product should be readily available.
As cool as the SGI FUEL system looks on paper, and as cool as the case looks in person, it provides poor value.
We've successfully ported our high end graphics/ video application from the SGI platform to Linux running on a high end dual-xeon workstation.
The Linux/Intel performance is more than double that of the fuel system, and our apps push the system to its limits. And, even figuring in the cost of the high end video boards, the Linux/Intel solution is 1/4 of the FUEL price.
It's very easy to justify the porting cost.
Is there anything about the iPod that would preclude it from supporting Ogg/Vorbis in a future software update?
In most cases I would agree with you. I generally ignore extended warranties on small ticket items at a department store or an elecontrics shop out of hand, because I know that they are generally poor value propositions.
However, the specific case of the applecare extended tech support/full hardware warranty on an iBook is different.
A laptop *is* likely to break at some point over a three-year span either from mechanical failure or (more likely) by human accident, especially if you are in a college environment. The minimum cost for a iBook repair is about $350, and the average cost is significantly higher. If you manage to damage your display screen, you might as well write the whole unit off.
The applecare warranty is a good value.
250$ for the extra 2 years of no-questions-asked tech support is exactly what you want if you're a college student. Do you really think your laptop is going to make it through college in one piece?
As a comparison, try checking the prices of in-store maintenance contracts for the same hardware. You'll find Apple is more than reasonable.
On the flip side, consider that any hardware repair at all after the first year will run you at least 350$ for parts and labor. You're foolish not the get the applecare warranty.
Remember that apple systems have a longer lifetime than typical PC counterparts. You're going to be using that ibook for a long time to come, you might as well take care of it.
Replying to my own post with extra information for the benchmark-interested..
The benchmarks were performed with IOzone on top of an ext3 file system. Write caching for the IDE drive was DISABLED, which adds latency to write calls and is somewhat responsible for the lower scores.
I've learned the hard way that leaving the write caching on (the default setting!) on an IDE drive can hose even a journaled filesystem during a system hang or sudden power loss event. Does anyone know if there is any way around this problem, other than disabling write caching?
I've benchmarked our various disk subsystems heavily.
Once you get exhaust the on-disk cache and the filesystem cache, the raw disk access speeds are visible. Here's what I've found for Seagate ATA-IV 80MB drives:
Sustained Sequential read: 40MB/sec
Sustained Sequential write: 17MB/sec
That was benchmarked on a 2Gz dual Xeon system under linux with nothing else running, and IDE tuned optimally. So, real life results are going to be worse.
It would not surprise me to see most consumer level systems with sustained speeds on a single disk under 10MB/sec. Most systems that use IDE drives don't have the DMA/ATA mode settings tuned aggressively.
Most systems with RAIDs have crappy implementations. Get a hardware RAID controller with its own processor and a large-bandwidth backend bus (ie, SCSI-160 or higher) and with lots of onboard battery-backed memory so you can safely turn on write caching.
I would respectfully disagree with your position on reselling "RedHat Linux". You can distribute Linux any way you want as permitted by the GPL, but RedHat has a right to their trademark. You have to call your distribution something other than RedHat. Only RedHat has the right to use the RedHat trademark.
This isn't "making life difficult", it's the way business is done. You make yourself look like an ass when you attack RedHat for requesting that you respect their trademark.
There are many different legal mechanisms one can use to control distribution of software.. Off the top of my head, I know of:
Copyright
Patents
ShrinkWrap Licenses
Technical Means (DMCA in the USA)
I personally disagree with the implementation of most the above. Copyright terms are too long, Patents are given out frivolously for types of things I personally don't believe should be patentable (business methods, software, algorithms), Shrinkwrap licenses are a one-sided travesty of a contract, and represent a blatant effort to avoid consumer protections based on ownership, and the DMCA is just an unjust pile of total crap.
Of the above, copyright is the least objectionable distribution control device. Therefore, I prefer licenses that rely soley on copyright rather than one of the other means.
I would be very much put off by a license that enforced the use of a click-through agreement. I dearly hope OSI and the FSF reject such things.
Am I the only one who thinks that upstream caps are a bad idea?
I don't want a 3Mb/328kb asymterical connection.. but I'd easily pay 80$ for 1.5Mb symmetrical. What is the problem here? Why do I get the feeling one of the big reasons an upstream cap exists is to create an artificial scarcity of servers? What does the telco care what I use my bits for, so long as I am paying?
Slightly off topic, but the apache project's log4j is the most elegent evolution of the "printk" school of debugging I have seen to date.
You can log against any backend source you feel like, flat files, syslog, databases, etc. You can remove the logging module entirely at runtime, without paying a performance hit for the debug statements. This saves a lot of jumping back and forth when you're trying to package up a release. If you're stuck without the fund$ for a top-end debugger it's the next best thing. It's for java, but I don't see any reason why the concept couldn't be ported to C++.
Looking at the data, it looks the two samples where Ogg performed poorly ended up being encoded at a significantly smaller average bitrate than any of the other encoders.
The table at the end lists LiszBMinor with an average ogg bitrate of 45 and BachS1007 with an average bitrate of 47. Since the other codecs encoded those samples at a bitrate 64 or higher, this may explain the results.
The results may point to a flaw in Ogg's VBR login rather than in the lossy compression scheme.
I agree with the observation that SiS has been an unexpected dark horse mobo/chipset candidate lately.
One correction though: Last I heard it was not a proven fact that Via doesn't have a "valid" P4 license. Via claims that the license is valid because they purchased S3, and S3 had a license. Intel claims S3's license was not transferrable. It seems the case is still up the in air, and the lawyers will have to sort it out. Via does seem to have a reasonable claim to the license, however.
Does someone want to briefly outline the major javascript compatibility differences between NS4, NS6/Mozilla, and IE?
I keep hearing second hand information from web developers that Mozilla's javascript implementation "breaks" compatibility, whatever that means.