Sponsors
Sponsor Products
late 80's style.
posted by Greg Whynott  on Dec. 22, 2016, 6:35 p.m. (3 years, 7 months, 12 days ago)
4 Responses     0 Plus One's     0 Comments  

Was poking around on one of the VM hosts and was pleasantly surprised to see it had over 100 gigs of DRAM in it with 50% un allocated/reserved. It was upgraded since the last time I touched them apparently....
Just want I needed as I wanted to double the memory allocated to the exchange server running on it. Looking at other guests on it, things seem 'normal'.. monitor machine 4 gigs, spam 4 gigs, db 8 gigs, sso/auth proxy 2 gigs and so on..
Then I see this:


lol Andrew!!! 128 megs. love it. This is our main kickstart/pxe boot, tftp image deployment server, has been in service for over 5 or 6 years now. Never once noticed it was acting sluggish. Reminds me of the days my Indy only have 8 megs, thought I was being silly upgrading it to 16 and 32 megs would be just showing off. lol. UNIX!!!!


the kicker is it seems happy, not a single page in swap:
root@pxe1:/install/centos73/repodata# free total used free shared buffers cachedMem: 121840 119012 2828 0 7476 26632-/+ buffers/cache: 84904 36936Swap: 0 0 0root@pxe1:/install/centos73/repodata#

merry christmas all!!greg





Thread Tags:
  discuss-at-studiosysadmins 

Response from Greg Whynott @ Dec. 22, 2016, 9:05 p.m.
lol didn't even consider the name. Made me think of that video that was going around after the flight 214 crash at SFO airport.. https://youtu.be/17GbGmDORwk
-g
On Thu, Dec 22, 2016 at 8:53 PM, Will Rosecrans <wrosecrans@gmail.com> wrote:
The person who became the manager by the end of the software project that was too slow was named Way Ting? Seriously?
Anyhow, I think that the basic premise that 10 Megabytes of software is too big and complicated for anybody to actually understand is still very true. It's a fascinating reminder that there was once a time when it was possible to understand a computer.
On Thu, Dec 22, 2016 at 4:19 PM, Jean-Francois Panisset <panisset@gmail.com> wrote:
Today is kind of a virtual Friday, and since Greg brought up the Indy, I figured I would post a link to a classic piece of SGI lore, the famous leaked internal report on the IRIX 5 fiasco.

https://www.cs.virginia.edu/~weimer/2009-4610/reading/irix-bloat.txt

Basically SGI marketing insisted that the Indy should be released with 16MB of RAM to hit a specific price point, whereas engineering was going on the assumption it would be a 32MB system. The result: a 16MB Indy running IRIX 5.1 was basically useless and would swap itself to death just sitting idle.

There's actually some interesting stuff in there which is still valid today, the tension between what marketing/sales wants to ship and what engineers know they can ship remains completely relevant today.

JF



On Thu, Dec 22, 2016 at 3:30 PM, greg whynott <greg.whynott@gmail.com> wrote:

Was poking around on one of the VM hosts and was pleasantly surprised to see it had over 100 gigs of DRAM in it with 50% un allocated/reserved. It was upgraded since the last time I touched them apparently....
Just want I needed as I wanted to double the memory allocated to the exchange server running on it. Looking at other guests on it, things seem 'normal'.. monitor machine 4 gigs, spam 4 gigs, db 8 gigs, sso/auth proxy 2 gigs and so on..
Then I see this:


lol Andrew!!! 128 megs. love it. This is our main kickstart/pxe boot, tftp image deployment server, has been in service for over 5 or 6 years now. Never once noticed it was acting sluggish. Reminds me of the days my Indy only have 8 megs, thought I was being silly upgrading it to 16 and 32 megs would be just showing off. lol. UNIX!!!!


the kicker is it seems happy, not a single page in swap:
root@pxe1:/install/centos73/repodata# free total used free shared buffers cachedMem: 121840 119012 2828 0 7476 26632-/+ buffers/cache: 84904 36936Swap: 0 0 0root@pxe1:/install/centos73/repodata#

merry christmas all!!greg





To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe


To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe


To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe


0 Plus One's     0 Comments  
   

Response from Will Rosecrans @ Dec. 22, 2016, 8:55 p.m.
The person who became the manager by the end of the software project that was too slow was named Way Ting? Seriously?
Anyhow, I think that the basic premise that 10 Megabytes of software is too big and complicated for anybody to actually understand is still very true. It's a fascinating reminder that there was once a time when it was possible to understand a computer.
On Thu, Dec 22, 2016 at 4:19 PM, Jean-Francois Panisset <panisset@gmail.com> wrote:
Today is kind of a virtual Friday, and since Greg brought up the Indy, I figured I would post a link to a classic piece of SGI lore, the famous leaked internal report on the IRIX 5 fiasco.

https://www.cs.virginia.edu/~weimer/2009-4610/reading/irix-bloat.txt

Basically SGI marketing insisted that the Indy should be released with 16MB of RAM to hit a specific price point, whereas engineering was going on the assumption it would be a 32MB system. The result: a 16MB Indy running IRIX 5.1 was basically useless and would swap itself to death just sitting idle.

There's actually some interesting stuff in there which is still valid today, the tension between what marketing/sales wants to ship and what engineers know they can ship remains completely relevant today.

JF



On Thu, Dec 22, 2016 at 3:30 PM, greg whynott <greg.whynott@gmail.com> wrote:

Was poking around on one of the VM hosts and was pleasantly surprised to see it had over 100 gigs of DRAM in it with 50% un allocated/reserved. It was upgraded since the last time I touched them apparently....
Just want I needed as I wanted to double the memory allocated to the exchange server running on it. Looking at other guests on it, things seem 'normal'.. monitor machine 4 gigs, spam 4 gigs, db 8 gigs, sso/auth proxy 2 gigs and so on..
Then I see this:


lol Andrew!!! 128 megs. love it. This is our main kickstart/pxe boot, tftp image deployment server, has been in service for over 5 or 6 years now. Never once noticed it was acting sluggish. Reminds me of the days my Indy only have 8 megs, thought I was being silly upgrading it to 16 and 32 megs would be just showing off. lol. UNIX!!!!


the kicker is it seems happy, not a single page in swap:
root@pxe1:/install/centos73/repodata# free total used free shared buffers cachedMem: 121840 119012 2828 0 7476 26632-/+ buffers/cache: 84904 36936Swap: 0 0 0root@pxe1:/install/centos73/repodata#

merry christmas all!!greg





To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe


To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe


0 Plus One's     0 Comments  
   

Response from Greg Whynott @ Dec. 22, 2016, 8:55 p.m.
and 5.3 was the result of that effort of change apparently, it was a popular release that had staying power on many servers. Then 6.2 was the next solid release if I recall..
It would be nice if SGI released internal emails from back then, de-identified if need be.. they played a big role for a short time in history, the catalyst to much innovation world wide. should be public record after a period of time has passed. ;)
-greg

On Thu, Dec 22, 2016 at 7:19 PM, Jean-Francois Panisset <panisset@gmail.com> wrote:
Today is kind of a virtual Friday, and since Greg brought up the Indy, I figured I would post a link to a classic piece of SGI lore, the famous leaked internal report on the IRIX 5 fiasco.

https://www.cs.virginia.edu/~weimer/2009-4610/reading/irix-bloat.txt

Basically SGI marketing insisted that the Indy should be released with 16MB of RAM to hit a specific price point, whereas engineering was going on the assumption it would be a 32MB system. The result: a 16MB Indy running IRIX 5.1 was basically useless and would swap itself to death just sitting idle.

There's actually some interesting stuff in there which is still valid today, the tension between what marketing/sales wants to ship and what engineers know they can ship remains completely relevant today.

JF



On Thu, Dec 22, 2016 at 3:30 PM, greg whynott <greg.whynott@gmail.com> wrote:

Was poking around on one of the VM hosts and was pleasantly surprised to see it had over 100 gigs of DRAM in it with 50% un allocated/reserved. It was upgraded since the last time I touched them apparently....
Just want I needed as I wanted to double the memory allocated to the exchange server running on it. Looking at other guests on it, things seem 'normal'.. monitor machine 4 gigs, spam 4 gigs, db 8 gigs, sso/auth proxy 2 gigs and so on..
Then I see this:


lol Andrew!!! 128 megs. love it. This is our main kickstart/pxe boot, tftp image deployment server, has been in service for over 5 or 6 years now. Never once noticed it was acting sluggish. Reminds me of the days my Indy only have 8 megs, thought I was being silly upgrading it to 16 and 32 megs would be just showing off. lol. UNIX!!!!


the kicker is it seems happy, not a single page in swap:
root@pxe1:/install/centos73/repodata# free total used free shared buffers cachedMem: 121840 119012 2828 0 7476 26632-/+ buffers/cache: 84904 36936Swap: 0 0 0root@pxe1:/install/centos73/repodata#

merry christmas all!!greg





To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe


To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe


0 Plus One's     0 Comments  
   

Response from Jean-Francois Panisset @ Dec. 22, 2016, 7:20 p.m.
Today is kind of a virtual Friday, and since Greg brought up the Indy, I figured I would post a link to a classic piece of SGI lore, the famous leaked internal report on the IRIX 5 fiasco.

https://www.cs.virginia.edu/~weimer/2009-4610/reading/irix-bloat.txt

Basically SGI marketing insisted that the Indy should be released with 16MB of RAM to hit a specific price point, whereas engineering was going on the assumption it would be a 32MB system. The result: a 16MB Indy running IRIX 5.1 was basically useless and would swap itself to death just sitting idle.

There's actually some interesting stuff in there which is still valid today, the tension between what marketing/sales wants to ship and what engineers know they can ship remains completely relevant today.

JF



On Thu, Dec 22, 2016 at 3:30 PM, greg whynott <greg.whynott@gmail.com> wrote:

Was poking around on one of the VM hosts and was pleasantly surprised to see it had over 100 gigs of DRAM in it with 50% un allocated/reserved. It was upgraded since the last time I touched them apparently....
Just want I needed as I wanted to double the memory allocated to the exchange server running on it. Looking at other guests on it, things seem 'normal'.. monitor machine 4 gigs, spam 4 gigs, db 8 gigs, sso/auth proxy 2 gigs and so on..
Then I see this:


lol Andrew!!! 128 megs. love it. This is our main kickstart/pxe boot, tftp image deployment server, has been in service for over 5 or 6 years now. Never once noticed it was acting sluggish. Reminds me of the days my Indy only have 8 megs, thought I was being silly upgrading it to 16 and 32 megs would be just showing off. lol. UNIX!!!!


the kicker is it seems happy, not a single page in swap:
root@pxe1:/install/centos73/repodata# free total used free shared buffers cachedMem: 121840 119012 2828 0 7476 26632-/+ buffers/cache: 84904 36936Swap: 0 0 0root@pxe1:/install/centos73/repodata#

merry christmas all!!greg





To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe


0 Plus One's     0 Comments