Thank You Firestorm Team

[Peggy Paperdoll]

Though I was exaggerating a little, I am a little serious.  More features mean more code (and potential bugs) and more code require larger file sizes.  With all the features and additions that I constantly hear here in the forums I don't think a viewer reaching the gigabyte range out of the question at all.......and when that happens, how long before a couple gigs? 

That last viewer I installed that I noticed the file size was one of the earlier V-3 viewers........if I remember correctly it was well over 30 megabytes.  When I first started SL I was amazed that the viewer was 20 megs in size.  It just keeps getting larger and larger........when will it stop?  I can't believe it takes that much space for what amounts to a browser.  Some serious streamlining is going to have take place at some point in time.

[Ansariel Hiller]

Those numbers refer to the installer size and have nothing to do with the actual size after installation. Currently, that are 107 MB for the official viewer and 182 MB for Firestorm - and that is far away from from a Gigabyte! And the main reason for that difference is the amount of skins and included dictionaries. The difference in code itself are roundabout 800 KB for the executable file. So it's pretty much nonsense of talking about Gigabytes of space being required for the tons of features more compared to the official viewer.

BTW: It's always pretty much amusing how some bloggers compare installer sizes of the different viewers. If the installer of a viewer is 20 MB or 30 MB is completely pointless as whatever viewer you choose, it will transfer roundabout 300 MB per hour of data from and to the SL servers!

[Peggy Paperdoll]

You're missing the point.  But, for you, I'm sure that's irrelevant.  My point is that asking for more features does two things (well more than that but two major things).  It introduces more for the users to use.  It gives users features and things that only a portion of the users will ever use (for various reasons).......most of the features and things given are not going to be used by anyone (some will use things other find useless and vise-versa).  That causes confusion for some who don't know what the feature does anyway.  Keeping it simple and allowing third parties to create features that those who want them is the best way to avoid that confusion (yeah, there will still be users who still don't know what it does but want it anyway........until it causes confusion or problems).  And the second big thing it does is increase the file size for the program.......some huge files are necessary for feature rich and powerful programs (GIMP and Photoshop come to mind).  But any SL viewer is nothing more than a specialized browser........that's all the viewers are.  As an example I just checked file sizes for SL V-3 and Internet Explorer (two browsers).  SL, as you said is 107 MB in size.........and more importantly (which you did not mention) is the size on disk.  That size is 122 MB (on a 64 bit Windows 7 installation).  Internet Explorer 9 consumes 5.70 MB (5.75 MB size on disk).  The size on disk is important because that size is what is actually taken up on your hard drive to house the program.........your file structure of your operating system will determine exactly how much space is used on the drive.  NTSF 64 bit is my file structure.

My point is the SL viewer is huge for what it is (a browser).  It's nearly 4 times the size of Internet Explorer and no one has ever accused Microsoft of coding efficient programs.  Start adding features and wish lists to the viewers and you can quickly get way out of line.........it's not inconcievable that a viewer for SL can approach a gigabyte in size (not likely to happen but it could).  With the viewer already as large as it is adding more to it will need to be done causiously............or that "not likely to happen" will become "likely to happen".  The SL server code and viewer code has grown over the years.  Much of that growth has been done by simply adding to the code........no going back and streamling before those additions.  That has produced bugs (as we all know) but it also produced what I've been told by coders is "spaghetti code".  Inefficient and prone to huge problems.........and I just said to be careful what you wish for when wanting more features.  At some point in time the whole thing just quits working.

[Ansariel Hiller]

You are turning the arguments just as you need them, do you? Because first you say wanted features should be create by third parties - guess what we are doing and and how many features are requests by users? But since the vast majority of the users don't know how to create those features themself, somebody has to do them and that's why we include them in the viewer. So looking into my glassbowl I predict next thing you will say is something like "make a lean viewer and implement a plugin interface so other third parties or users can create plugins". And when I say "hey that's a great idea!" you come up with the everyone is untrustworthy argument! Furtunately there are several viewers you can choose from. It's not that we force you to use Firestorm or any other third party viewer. If you feel comfortable with the LL viewer, then for god's sake use it!

Regarding the file size: Sorry, but that's just plain stupid nit-picking! It's 2013 and not 1993 and if the viewer's executable is 5 MB or 50 MB is pretty much irrelevant due to the capacity of current hard discs. Same as we don't need to squeeze the last bytes out of the 640 KB conventional memory anymore. And comparing it to Internet Explorer... Of course you also added all those DLLs in the Windows system folders that belong to the Internet Explorer as it hooks deeply into the operating system, correct? But the SL viewer does a lot of things more than a web browser and compared to other games this is a joke. But if you want a lean viewer, maybe you should use Radegast - oh well, forgot: It's a third party viewer.

TLDR: If you prefer V3 then use it, but your arguments made up out of thin air.

[Peggy Paperdoll]

I use V-3 by choice.  I have a pretty powerful computer by most standards, I have plenty of memory (16 gigs).  I have a terrabyte of storage.  I can run any viewer out there will very little, if any, trouble.  I'm not talking about my machine or your machine........I'm merely saying that, for the everyday, average computer the viewers are getting close to the point of being overly bloated.  My points are valid unless you are only talking about my computer or your computer.....what about the average user with little or no knowledge about what is happening when they run SL (or any program, for that matter).  Efficient, light weight code is king........it was king back in 1993 and remains king in 2013 (it will still be king in 2023).

But I'm not arguing anymore......this is a de-rail because I mentioned that one should be careful about what they wish for.  I'm not here to demonstrate my knowledge about computers and/or code.  I have a fair amount computer knowledge and almost no coding knowledge........only that bloated code and inefficient code do not work well (that is common knowledge, by the way).

[solstyse]

Oh no. 122mb out of roughly 500000 that the average disk is rated. that only leaves us with.... too many left to count on our fingers and toes left! hahaha. Kind of puts it in perspective, doesn't it?

Seriously though. Programs typically get larger. That's life. And HDD space isn't exactly hard to come by. Even if you do fill up a hdd, then it's one of the few pieces that you can upgrade in even a laptop. Don't want to upgrade? Certainly out of 500gb not every single file needs to be on your bootable hard drive. Move some stuff to flash drives, or burn some dvd's or something.

that being said, though, I'd really, really like to know why it is that the same people who tell me that I don't know what I'm talking about when I suggest some optimization suddenly love the idea when it's their turn to type it.

Storage problems are a thing of the past. The current concern is power being traded for size and battery life in modern machines. Memory usage, cpu usage, and graphics handling are all major concerns. File size isn't.

[Peggy Paperdoll]

"...

...File size isn't."

---------------------------------

Until it takes 2 times 3 times, half a dozen times for the program to load.  Or for for the program to dump the cached files so it can start fresh.  File size does effect how a program runs.  No it's not a major concern if the program is well written where there is little or no time spent moving from one portion of a HDD to another to get all the data in memory so it can be processed........but for software like the SL viewers that's not the case.  Something simple when it's scattered all over the program files can be very complicated.......and take many times more than necessary for the task to be accomplished.  Why do you suppose so many people have problems with SL?  It's not that so much what the viewer is doing, but how it's forced to do it........that happens when programs are added to without re-writing the code that is already written in a more efficient way.  Get a large program that is not efficient and the problem magnifies. 

Bloated software, no matter how much disk space you may have, is never good software.  The viewers are becoming quite bloated as it is now.  Keep adding to it and it's going to get worse.......not better.  Scatter 107 MB across a GB of storage and the program starts having problems (that's an exxaggeration to emphasize a point......it happens when your HDD becomes fuller.  Even after defragging).

[Dillon Levenque]

Kind of continuing with the derail, but what you mentioned is something I see a lot. I have come to believe that, at least for the big players, programmers get the latest and greatest computers to work with. So, naturally, the stuff they code is built to work really well on the latest and greatest. Maybe I'm wrong but in my industry that's how it works. A vendor will come out with a new version of the application (by the way, the previous version is no longer supported; no more bug fixes) but to install it our customers will need a new server with a new OS.

I get the idea programmers now have more room than they need. Programs DO get bloated, as you suggest. I mean, what the heck—plenty of room on the average HDD. There used to be a phrase used about programming that was done well: elegant. Finding a way to accomplish the task in the fewest possible steps. LSL scripters, I'm sure, strive for that all the time. I feel the need for elegance in PC applications has gone by the wayside and that's too bad.

[solstyse]

I'm glad you seem to know that my wording was just a friendly jest. After I posted I thought it could be taken wrong. I'm relieved it wasn't.

File size may be the worst way to express it. I agree 100% with what you're saying. Anything that lowers demand while keeping existing features intact is a good thing. I really wish that LL would put the new stuff on pause, and say, "Let's clean up what we already have first.." Likewise, if they won't I wish that a TPV would take the base viewer code, and instead of making it unique by adding features, would clean up a little.

That's kind of what I've been getting at all along. Even in other threads where you and I have talked, agreed, and even disagreed. Maybe the way I was expressing it was just as ineffective as the way I see you using file size as a way to express it. But it seems that while we're talking from opposite sides, what we're both wishing for is sleeker, more efficient code.

[Peggy Paperdoll]

Actually, it's program size (or folder size).  You're right file size is not exactly what I should have used.  But, no matter what you call it the total bits and bytes that make it work should always be the bare minimum necessary.......in theory, that is. In reality there is always going to be "bloat".  But good software always has less bloat than bad software.  Anything the code does that puts more processing than necessary in the mix is slower and more prone to issues than code without that extra processing requirement.  The SL code grew up over the years......it has never been re-written.  There are bugs that rear their ugly heads today that were around back in 2005 that I know of..........bugs that have been "fixed" several times over.  That should not happen but it does so it's quite obvious to me that the code is very inefficient and extremely bloated.  Keep adding features and not cleaning up the existing code in the process and everything will simply stop working........then, someone will be forced to re-write the code (or just let it die and go into the history books).

[solstyse]

I think in this thread you and I have finally found our common ground. Maybe the difference is that I feel optimistic that with the merging of formfactors cleaner code is the inevitable result, while you're more pessimistic? We definitely seem to have a common goal.

I think in other threads the reason why you and I have butted heads is because I feel that the future necessitates progrrams running on multiple platforms, which will take hardware demands to the lowest common denominator (meaning more efficient code to make up for the lack of capability in certain devices)  If I'm reading your posts right, it seems like you're more conviced that things will simply pause as they are to give those less cabaple devices time to catch up.

If that's the case, then I hope for LL's sake that I'm right. That the devices tat are sold with lesser capability are the ones that will be marketed to in the near future.

Times are different now. Microsoft isn't the only game in town, and it seems like they know it. Now they compete with Linux, OSX, IOS, and Android. I feel that at this point, for any software to be considered successful, it must work smoothly on the least capable of all, while not lacking any of the features that the most cappable can take advantage of.

 

[Ansariel Hiller]

That is called evolution! Yes, I also would like to see the crappy viewer being rewritten from scratch, but that simply won't gonna happen because it's far too expensive. So we're stuck with what we have and can only try to fix it ourself and add stuff people want. And since about 75% of all users in SL use a third party viewer, it's quite obvious that most people think there's something wrong with the official viewer. But again: If you like it, then use it. Easy as that.

The other part about file and folder sizes only gets more and more rediculous. With regard of the viewer, I'd then suggest you to not use and cache or use a RAM disk for the cache as it fragments data and leads to slowdowns. That's basically against the idea of a cache if you would have to reload it over the Internet all the time, but at least the program starts fast!

With that being said, I'll look for an old copy of Windows 3.1 and will send it to you in case you need it and want to get rid of those bloated operating systems like Windows 7 - oh wait! There is a solution called Windows 8 that comes with less options where somebody else already decided what you want (to have)!

[Perrie Juran]

---

Peggy Paperdoll wrote:

Actually, it's program size (or folder size).  You're right file size is not exactly what I should have used.  But, no matter what you call it the total bits and bytes that make it work should always be the bare minimum necessary.......in theory, that is. In reality there is always going to be "bloat".  But good software always has less bloat than bad software.  Anything the code does that puts more processing than necessary in the mix is slower and more prone to issues than code without that extra processing requirement.  The SL code grew up over the years......it has never been re-written.  There are bugs that rear their ugly heads today that were around back in 2005 that I know of..........bugs that have been "fixed" several times over.  That should not happen but it does so it's quite obvious to me that the code is very inefficient and extremely bloated.  Keep adding features and not cleaning up the existing code in the process and everything will simply stop working........then, someone will be forced to re-write the code (or just let it die and go into the history books).

---

This highlights a problem, something that goes on in the background, that oftentimes we are not aware of the technical difficulties.  A building is only as strong as its foundation.  The original foundation that SL was built on had weaknesses, some of which did not become apparent until LL started to add more bells and whistles to SL.

So now work a rounds have to be added.  To wear Mesh Clothes generally speaking you need to wear an Alpha if the don't  want boobs popping out of the dress.  THAT is  a work around.  Because the dress doesn't conform properly to your shape.  And it adds load to the system.

Some of us would like to see the so called Avatar 2.0.  But the (questionable) problem with it is the amount of current content it would break.

As to the other issue of "Viewer Bloat," it does come down to performance versus options.  But really you've always had that in the Viewer.  Want things to run faster, turn down your graphics.  Want greater detail, turn them up but the World may appear to move slower, i.e. Viewer side Lag.

I like some of the extra options Firestorm affords me.  Do they add load to my system.  Probably.  But for me it is worth the trade off.  If for someone else such as yourself it isn't worth the trade of, there are other options available.

I would add as a side note, back when I had all my problems with my Frame rate collapsing when Mesh went live, one of the oddities at the time was that I got double the frame rate (10FPS versus 5FPS) using Firestorm rather than the Official Viewer.  This problem vaporized when I finally upgraded my computer from Win XP to Win7, a whole nother oddity.  SL runs pretty smooth for me now!