[Info-vax] portable sequential file formats (was: Re: Couple of questions on VMS -> world)

Bill Gunshannon bill at server3.cs.scranton.edu
Thu Mar 19 08:40:11 EDT 2015


In article <e55c1de3-ce3d-42b0-a124-601139249739 at googlegroups.com>,
	johnwallace4 at yahoo.co.uk writes:
> On Thursday, 19 March 2015 01:11:23 UTC, Stephen Hoffman  wrote:
>> On 2015-03-18 23:38:21 +0000, johnwallace4 at yahoo.co.uk said:
>> 
>> > On Wednesday, 18 March 2015 01:22:16 UTC, johnso... at gmail.com  wrote:
>> >> On Tuesday, March 17, 2015 at 1:00:04 PM UTC-4, li... at openmailbox.org wrote:
>> >> 
>> >>> Agreed. I don't understand how anybody can use Linux or most UNIX in
>> >>> production for anything.
>> >> 
>> >> But clearly it's been done and continues to be done. At quite large scales too.
>> >> I think of organizations such as Amazon, Twitter, Facebook, Google. Perhaps
>> >> you are focusing on the wrong things.
>> >> 
>> >>> But it's still UNIX so it suffers from the same lack of naming conventions
>> >>> and where Sun hasn't fixed [...]
>> >> 
>> >> While annoying at times, it's really not a deal breaker. It's at most a 
>> >> temporary
>> >> speed bump for some.
>> >> 
>> >>> And they're all based on C which is the root of all evil- it's
>> >>> not *if* something bad is going to happen it's just when and how often.
>> >> 
>> >> I think you need to separate your disgust at elements of the standard C
>> >> library from that of the language itself.
>> >> 
>> >> EJ
>> > 
>> > 
>> > Twitter, Facebook, Google, etc are presentation-centric read-mostly
>> > applications, on the whole. Nobody cares much if they work properly
>> > or not, so long as they're mostly there most of the time.
>> 
>> The billing and ad-tracking systems are rather more robust, I'd expect. 
>>  That written, Facebook and others have done some very serious work on 
>> distributed computing and scaling.  <https://github.com/facebook>, 
>> among others.  As for not the social sites working properly or not, 
>> outages and errors are a big problem for ad-driven social sites.  If 
>> the sites are not around and not keeping their users happy and 
>> entertained, then the sites are not adding content and not making 
>> money.  At the scale of Facebook, keeping these servers online and 
>> operational and secure is not an easy problem.   VMS supports nothing 
>> even close to the scale of many modern configurations, for that matter. 
>>   A hundred nodes is three Moonshot boxes in ~13U, after all.
>> 
>> > Equally, nobody notices much if they provide wrong data or lose data
>> > from time to time. These are the outfits who are the target market for
>> > HP/Foxconn's Cloudline disposable/nonmanageable/nondiagnosable servers.
>> 
>> RAIS.   Quite popular in some quarters, particularly as the costs of 
>> the servers crater.  Why bother fixing something, when your software -- 
>> akin to clustering on VMS, but at much larger scale -- can simply swap 
>> in another box as needed.    Yes, scribes tell us that in the 
>> eldertimes, computer technicians known as Field Servants used to 
>> perform component-level repairs, and servers got periodic preventive 
>> maintenance visits, but can you believe the costs involved with that 
>> sort of thing now?  Scribes tell us that disks were once repaired, and 
>> boards and were HDAs swapped around.
>> 
>> BTW, it's possible to get into trouble with first-tier server gear 
>> (with design and software issues), too 
>> <http://jacquesmattheij.com/saving-a-project-and-a-company>
>> 
>> > These well known outfits buy lots of kit but how representative are they
>> > of the rest of the market? If you want a disposable webfacing
>> > presentation-centric public setup, why not leave it to e.g. Amazon AWS
>> > and the like, and forget about the hardware altogether?
>> 
>> Requirements differ: 
>> <http://highscalability.com/blog/2015/3/16/how-and-why-swiftype-moved-from-ec2-to-real-hardware.html> 
>> 
>> 
>> > But if you want a traditional transactional setup where data
>> > availability and integrity and security are still things that matter,
>> > there may be better options.
>> 
>> One question there being whether VMS is one of those better options, 
>> particularly for new deployments.   Up until July 2014, the answer to 
>> that question was usually "no".
>> 
>> > One size does not fit all?
>> 
>> Ayup.  That's why we're not all running {whatever}.
>> 
>> > "separate your disgust at elements of the standard C library from that 
>> > of the language itself. "
>> > 
>> > Lots of folk could benefit from doing that.
>> 
>> Ayup, and what will lists think of OpenVMS, given that more than a 
>> third of OpenVMS is written in C?   I'd be inclined to use something 
>> else now, but there's no-trivial cost involved in shifting languages.  
>> Adding another language to the existing collection of (mostly) C, 
>> Macro32 compiler code, and Bliss -- and a variety of other bits in 
>> smaller quantities, including Ada -- just isn't going to be at the top 
>> of most lists.  Particularly given the current team generally knows C, 
>> Macro32 and Bliss pretty well, too.
>> 
>> 
>> -- 
>> Pure Personal Opinion | HoffmanLabs LLC
> 
> These scribes of whom you write, are they related to today's High
> Priests of today's One True Way, that shall be called the Holy Cloud
> (and yesterday, when it shall have been called the Virtually Holy
> Window Box)?
> 
> Faith-based (or fashion-based) IT doesn't work any better than
> faith-based (or fashion-based) engineering. But there's a remarkable
> amount of them around. 

Yeah, they are called Apple users.

>                        And, not surprisingly, from time to time there
> are stories of people who get their fingers burned by force fitting
> the trendy solution into a setup which an informed analysis might have 
> said up front could really do with something else.

bill

-- 
Bill Gunshannon          |  de-moc-ra-cy (di mok' ra see) n.  Three wolves
billg999 at cs.scranton.edu |  and a sheep voting on what's for dinner.
University of Scranton   |
Scranton, Pennsylvania   |         #include <std.disclaimer.h>   



More information about the Info-vax mailing list