> It is barbaric indeed. I'll have to borrow that quip some time :).
You are very welcome to it :)
Actually, my biggest overhead issue right now is storage. We have
hundreds of kids (per school) adding ~3.2MB each, 5 days a week.
Which is a bear in itself. Then we need backup. We are playing with
time of retention per dollar metrics right now to figure out what to
offer the customers.
This happens to be one of those problems we felt could be 'worked out'
during dev. And while we had some " Really Neat Ideas " (tm) on using
various CDN's to handle transcoding and active (cache headers) storage
while we rolled the objects not woken in x time from y time based on
popularity (time in between transactions and views measured against
views) into slower cheaper storage. ALL sorts of problems have
cropped up :)
The main one being that we have to handle our own transcoding because
the solutions offered by akamai, internap and limelight just don't cut
the mustard for the amount of content we are pushing to them.
On Sun, Dec 7, 2008 at 10:02 AM, B. Estrade <estrabd@gmail.com> wrote:
> On Sat, Dec 06, 2008 at 11:32:36PM -0600, Dennis J Harrison Jr wrote:
>> Ron, you sound like a friend of mine. He is constantly preaching to
>> me how much more math I should learn to write better programs. The
>> only thing I can say is:
>>
>> What is the real world benefit for me to write a program that runs 20%
>> to 300% 'faster'. When 50% of the current speed is more then enough?
>
> I think that actual problem is that sub-par implementations tend to use sub-par algorithms, which usually end up running thousands of times slower than they have to - even on the fastest current hardware. Never forget how vulnerable hardware is to poor solutions.
>
>>
>> You can argue resource management all day long. However I take those
>> things into consideration. Most of my programs have very limited
>> client side footprints. I know throwing more hardware at a
>> performance issue is barbaric. But I have not had to go there yet.
>
> It is barbaric indeed. I'll have to borrow that quip some time :).
>
>> We have SO MUCH head room on our infrastructure for our current
>> customer base... I can't see a reason to spend time making it more
>> efficient when I could spend time adding useful (to humans) code
>> instead.
>
> I agree, it's all about the practical considerations of what you're doing.
>
> Brett
>
>>
>>
>> On Sat, Dec 6, 2008 at 5:15 PM, Ron Johnson <ron.l.johnson@cox.net> wrote:
>> > On 12/06/08 15:07, Friedrich Gurtler wrote:
>> >>
>> >> On Sat, Dec 6, 2008 at 2:52 PM, Ron Johnson <ron.l.johnson@cox.net> wrote:
>> >>
>> >>> Python is a great learning scripting language, but new programmers *need*
>> >>> to know the hardware. Assembly programming, preferably in MS-DOS or
>> >>> CP/M,
>> >>> would be best.
>> >>>
>> >>
>> >>
>> >> Indeed, and don't let them get near a database before they have written
>> >> their own database engine. I mean, that might lead them to write something
>> >> less than perfectly optimal. We couldn't have that.
>> >
>> > What stupidity.
>> >
>> > Having to write rather complete binary tree and hash libraries has greatly
>> > aided me as a DBA, even though I've never had to use such a hand-rolled
>> > library in 20+ years.
>> >
>> >> Slide rules forever! =P
>> >
>> > Everyone on this list who lived thru Katrina know how dependent upon
>> > technology that Americans have become.
>> >
>> > Knowing how to use slide rules and magnetic compasses, read a map, start
>> > fires without matches, etc, etc are all very useful skills.
>> >
>> > --
>> > Ron Johnson, Jr.
>> > Jefferson LA USA
>> >
>> > How does being physically handicapped make me Differently-Abled?
>> > What different abilities do I have?
>> > ___________________
>> > Nolug mailing list
>> > nolug@nolug.org
>> >
>> ___________________
>> Nolug mailing list
>> nolug@nolug.org
>
> --
> B. Estrade
> Louisiana Optical Network Initiative
> +1.225.578.1920 aim: bz743
> :wq
> ___________________
> Nolug mailing list
> nolug@nolug.org
>
___________________
Nolug mailing list
nolug@nolug.org
Received on 12/07/08
This archive was generated by hypermail 2.2.0 : 12/19/08 EST