Duration and granularity of the lock are intertwined; if duration was near zero, granularity could be smaller. Think in terms of an online document collaboration program where a single document is shared by multiple editors, but the bandwidth is sufficiently high that everyone sees everyone elses keystrokes at the same time. Chaotic, but highly collaborative. Locks would be reduced to a single character. At the opposite end of the spectrum you have locks that cover entire database views for long periods of time -- generally batch, technically multi-use (but only grudgingly so). Locking is a big subject, very comp-sci.
Rowter it is here, mate. In Australia a "rooter" has a different meaning altogether, vis a viz "pig rooter" does not mean someone digging for truffles.
I agree pretty much on all points -- VMS and the Vax hardware was pretty well engineered, and the engineers they sent out tended to be well clued.
When I first compared the processor speed of a Vax 6500 with a 486 DX2, I realised it was game, set, match for my old friend, and the product set would soon be declared "stable" and other kisses of doom. When RDB was sold off to Oracle, that was it -- I jumped ship.
I can't help thinking though that VMS was a brilliant business engine with a superb control language, and a commodity hardware platform running it would still make sense. There's a lot of.COM files out there.
No, not really. It was a new project written specifically in response to shortfalls in MS Mail 3.x, a LAN-based pre-internet mail system with add-on SMTP and X.400 gateways (my first cert. Gawdawful thing!). It was purely an NT server-only initiative based around a pre-LDAP X.500 directory variant -- there was a/raw_mode switch that showed you a lot of x.400-style record addressing built on the JET database engine. It was very closely integrated with NT SAM (v3.51) and NT network stack, so I don't really think it was ever intended to be all that portable. X.500 was pretty much the only open standard around at the time that had any weight, and they went around that.
I value your opinion, and thank you for venturing it.
My evaluation was not exactly back-of-the-napkin though, but involved leading a $1M+ customer funded formal product evaluation team for a major national gov infrastructure organisation in Australia. That's a lot of money to evaluate one product, and we were pretty careful. Since we were talking several million mailboxes, the major issue was not centred around users per server so much as the ability to integrate that many users with reasonable response. Mail was the focus.
The 16GB limit (an admitted pain) was worked around by adding servers and carefully designing the site structures.
My involvement with the product started with TR 0 and finished around v5.5. I'll admit I only had a couple of years of comparable experience with Notes, but I do remember the comparative bandwidth issues seemed to favour Exchange, and the UI quality and ease of user admin became important at that scale.
Major sources of corruption tended to be (a) servers running out of disk space (generally when people didn't allocate a separate system partition), (b) intellectually-challenged users trying to run production off an MSDN development server, and (c) people who had never run the database tuning wizard. A well-designed structure didn't explode.
It was not all milk & honey (release 4.0 (really version 1)), but definitely more scalable within our context. YMMV of course. It's worth noting that your US Army uses it, and that's a very robust installation on a rather respectable organisation with some pretty heavy duty response requirements.
BTW our hopes and prayers to all you tin hats out there who are lacing up your boots and wishing you were somewhere else. Onya, mates!
I've spent a few years as an Exchange product support specialist as well as a Notes admin, and have spent 10 years as a DBA.
IMHO Exchange is definitely the better product for mail; it's fast and easy to shift connectivity, easy to track, can be made secure, and efficiently scalable. Based on a decent database core, and purpose built for the task. It does not poll directories on receipt prior to delivery to mailbox, which pleases the old driver writer in me (it's nice to hear people on the other end of a long distance line say "got it" the moment I hit Enter).
Notes is comparatively admin-hostile, is not quite as wysiwyg (hate that left character indent and lack of word skip) but has a much better and more reliable rules engine. It does not scale as efficiently, and can be a little too secure (do not lose your ID file). I find the decoupling of console admin tasks from observable effect disconcerting and nonintuitive. On the plus side it can be cheaper to buy into for SME's and there are quite a few add-on products available. Replication, however necessary for Notes, is a little unpleasant on bandwidth at times. Given a budget of my own, I'd go with Exchange (and I'm with a totally J2EE/*nix/squirrel mail shop now). I just wish there were a decent competitor out there in enterprise e-mail space with as nice a directory, shared folder and addressing scheme. IMNSHO Notes isn't it.
Perhaps not on the power lines themselves, but the right-of-way itself is a valuable commodity. Stringing coax across power poles can be fairly cheap if you own the power poles.
Supported x-windows too. Would be fun to compare cost-benefits for people who aren't terribly interested in the screen saver/doom market (e.g. helpdesks, etc.). Did I say DCL was a hoot?
It's not just the people, but the hopes of millions of people they represent, people who want to think we can leave the egg when the yolk runs out. A lot of emotion was invested, not just dollars and people. Get a hope.
As it turns out, the same person who designed VMS -- Dave Cutler -- designed Windows NT. VMS and NT are more closely related than 16-bit Windows was to Windows NT, once you get past the GUI. I believe a lot of the demand-paging algorithms were kept, although it was hard to map the KESU (kernel-executive-supervisor-user) hard shell address space to the Intel instruction set, which didn't support that many modes (and one of the reasons we've been suffering BSOD's ever since)
But DCL was the real peach -- batch queues were powerful, involuted, dangerous and somewhat feudal; security was utterly brilliant. I had zero breakins or hacks in 10 years as sysadmin/system programmer of a highly politically-sensitive site.
Loved VMS, moved to MS, got MCSE, moved to Unix/J2EE...
Have a look at the ARRL handbook (Radio Shack used to carry it) -- ham radio operator's bible from the Amateur Radio Relay League. Old copies ok. There are people who send RF to the other side of the globe on 1 watt transcievers, using clever antenna design. Good antenna design can make up for low power devices.
Ancient and venerable 24-bit CDC 3150 machine in 1970 solved buffer overflow problems by pre-writing return jump to execover (pass control to data area and bang, you're dumped) instruction throughout user space. When you got the dump, the ASCII interpretation was "ojoy". So you got about thirty pages of blue-bar printout saying "ojoyojoyojoyojoy...".
Thirty-three years in the industry, working for government, utilities, NASA, Big5 consultancies and small private shops, writing assembler and 6-character-identifier Fortran (among others), I think I've finally achieved Acronym Overload (AO) reading the title to this article.
I am now certain that my profession is entirely populated by aliens.
Test-first is not new, and yes it does work. We used it in the mid 70's for projects orgeom (orbital geometry) and cmdflgen (spacecraft command file generator) for the Pioneer 12/13 Venus orbiter and multiprobe, written in disciplined and highly modular Fortran IV under RSX-11M.
Writing a little UI for each module was easy, as we only passed a few parameters back and forth. It added perhaps 20% to our coding time at most, and easily saved back 100% over previous attempts. Being NASA, we had very absolute deadlines and had to keep a tight rein on disk space, but we did it anyway.
Also at Logisticon (now defunct) a little later, a bespoke supply chain app for JC Penny's with close to a million lines of Fortran.
Same techniques, except we had code reviews instead of pair programming, still test-first though. Result was maybe a dozen bugs per major release. The stuff worked; good techniques overcame a horrible development platform (GA-440/Fortran 66/iftran) for happy customers. Pretty extreme.
At which point we can roam the galaxy searching for civilisations and assimilating them, adding their biological uniqueness to our own. Around such a seed crystal as this magnificent monopoly, the Borg will form
"Bill Gates" is a contraction of "We Will Send You A Bill For All Logic Gates".
I've been in the IT industry for 33 years. I have an MCSE that I've never really used, keep it somewhere off in the fine print of the quals. Still glad I got it though (never completed the degree).
Two things: (a) keep your reading up. Never slack off on that, and (b) be willing to take on work beneath your skills and do more than you're asked. If you can't get a promotion you can leverage the experience for the next job.
One of the things that helps (I've read a *lot* of resumes) is to emphasize things you've done, not tools you've used; e.g. "I'm helping to build a cathedral" rather than "I'm laying bricks" point of view. Treat the tools you know as incidental to the job of helping your employer achieve their aims.
Cool idea! What's the largest grain of salt on record? Was it piezolectric? Could you carve a clock out of it? Build a house for saltwater fish? What's the biggest salt crystal you could grow before it fell apart from it's own weight?
I should know better than to press "submit" in that 15 second window after a extra-strong short black macciato...
Um, maybe a bit off-topic....
Slashdot Mirror
So long, and thanks for all the fish...
Duration and granularity of the lock are intertwined; if duration was near zero, granularity could be smaller. Think in terms of an online document collaboration program where a single document is shared by multiple editors, but the bandwidth is sufficiently high that everyone sees everyone elses keystrokes at the same time. Chaotic, but highly collaborative. Locks would be reduced to a single character. At the opposite end of the spectrum you have locks that cover entire database views for long periods of time -- generally batch, technically multi-use (but only grudgingly so). Locking is a big subject, very comp-sci.
Rowter it is here, mate. In Australia a "rooter" has a different meaning altogether, vis a viz "pig rooter" does not mean someone digging for truffles.
When I first compared the processor speed of a Vax 6500 with a 486 DX2, I realised it was game, set, match for my old friend, and the product set would soon be declared "stable" and other kisses of doom. When RDB was sold off to Oracle, that was it -- I jumped ship.
I can't help thinking though that VMS was a brilliant business engine with a superb control language, and a commodity hardware platform running it would still make sense. There's a lot of .COM files out there.
No, not really. It was a new project written specifically in response to shortfalls in MS Mail 3.x, a LAN-based pre-internet mail system with add-on SMTP and X.400 gateways (my first cert. Gawdawful thing!). It was purely an NT server-only initiative based around a pre-LDAP X.500 directory variant -- there was a /raw_mode switch that showed you a lot of x.400-style record addressing built on the JET database engine. It was very closely integrated with NT SAM (v3.51) and NT network stack, so I don't really think it was ever intended to be all that portable. X.500 was pretty much the only open standard around at the time that had any weight, and they went around that.
Ok, Mr. Ray Berry, why are you posting anonymously and cowardly?
My evaluation was not exactly back-of-the-napkin though, but involved leading a $1M+ customer funded formal product evaluation team for a major national gov infrastructure organisation in Australia. That's a lot of money to evaluate one product, and we were pretty careful. Since we were talking several million mailboxes, the major issue was not centred around users per server so much as the ability to integrate that many users with reasonable response. Mail was the focus.
The 16GB limit (an admitted pain) was worked around by adding servers and carefully designing the site structures.
My involvement with the product started with TR 0 and finished around v5.5. I'll admit I only had a couple of years of comparable experience with Notes, but I do remember the comparative bandwidth issues seemed to favour Exchange, and the UI quality and ease of user admin became important at that scale.
Major sources of corruption tended to be (a) servers running out of disk space (generally when people didn't allocate a separate system partition), (b) intellectually-challenged users trying to run production off an MSDN development server, and (c) people who had never run the database tuning wizard. A well-designed structure didn't explode.
It was not all milk & honey (release 4.0 (really version 1)), but definitely more scalable within our context. YMMV of course. It's worth noting that your US Army uses it, and that's a very robust installation on a rather respectable organisation with some pretty heavy duty response requirements.
BTW our hopes and prayers to all you tin hats out there who are lacing up your boots and wishing you were somewhere else. Onya, mates!
a cab meddles, host shot, loss?
IMHO Exchange is definitely the better product for mail; it's fast and easy to shift connectivity, easy to track, can be made secure, and efficiently scalable. Based on a decent database core, and purpose built for the task. It does not poll directories on receipt prior to delivery to mailbox, which pleases the old driver writer in me (it's nice to hear people on the other end of a long distance line say "got it" the moment I hit Enter).
Notes is comparatively admin-hostile, is not quite as wysiwyg (hate that left character indent and lack of word skip) but has a much better and more reliable rules engine. It does not scale as efficiently, and can be a little too secure (do not lose your ID file). I find the decoupling of console admin tasks from observable effect disconcerting and nonintuitive. On the plus side it can be cheaper to buy into for SME's and there are quite a few add-on products available. Replication, however necessary for Notes, is a little unpleasant on bandwidth at times. Given a budget of my own, I'd go with Exchange (and I'm with a totally J2EE/*nix/squirrel mail shop now). I just wish there were a decent competitor out there in enterprise e-mail space with as nice a directory, shared folder and addressing scheme. IMNSHO Notes isn't it.
I suppose the XBOX could make toast, provided Microsoft knows how long to boil it.
Perhaps not on the power lines themselves, but the right-of-way itself is a valuable commodity. Stringing coax across power poles can be fairly cheap if you own the power poles.
Supported x-windows too. Would be fun to compare cost-benefits for people who aren't terribly interested in the screen saver/doom market (e.g. helpdesks, etc.). Did I say DCL was a hoot?
They adopted the "Open" qualifier when they passed the Posix test suite.
It's not just the people, but the hopes of millions of people they represent, people who want to think we can leave the egg when the yolk runs out. A lot of emotion was invested, not just dollars and people. Get a hope.
But DCL was the real peach -- batch queues were powerful, involuted, dangerous and somewhat feudal; security was utterly brilliant. I had zero breakins or hacks in 10 years as sysadmin/system programmer of a highly politically-sensitive site.
Loved VMS, moved to MS, got MCSE, moved to Unix/J2EE...
Have a look at the ARRL handbook (Radio Shack used to carry it) -- ham radio operator's bible from the Amateur Radio Relay League. Old copies ok. There are people who send RF to the other side of the globe on 1 watt transcievers, using clever antenna design. Good antenna design can make up for low power devices.
Ancient and venerable 24-bit CDC 3150 machine in 1970 solved buffer overflow problems by pre-writing return jump to execover (pass control to data area and bang, you're dumped) instruction throughout user space. When you got the dump, the ASCII interpretation was "ojoy". So you got about thirty pages of blue-bar printout saying "ojoyojoyojoyojoy...".
I am now certain that my profession is entirely populated by aliens.
Absolutely. How else could I handle that third keyboard and mouse?
um, yeah. Remember Apple / UCSD Pascal? Compiled down to a "universal bytecode" which was then run by an interpreter. Go figure.
Writing a little UI for each module was easy, as we only passed a few parameters back and forth. It added perhaps 20% to our coding time at most, and easily saved back 100% over previous attempts. Being NASA, we had very absolute deadlines and had to keep a tight rein on disk space, but we did it anyway.
Also at Logisticon (now defunct) a little later, a bespoke supply chain app for JC Penny's with close to a million lines of Fortran.
Same techniques, except we had code reviews instead of pair programming, still test-first though. Result was maybe a dozen bugs per major release. The stuff worked; good techniques overcame a horrible development platform (GA-440/Fortran 66/iftran) for happy customers. Pretty extreme.
"Bill Gates" is a contraction of "We Will Send You A Bill For All Logic Gates".
Two things: (a) keep your reading up. Never slack off on that, and (b) be willing to take on work beneath your skills and do more than you're asked. If you can't get a promotion you can leverage the experience for the next job.
One of the things that helps (I've read a *lot* of resumes) is to emphasize things you've done, not tools you've used; e.g. "I'm helping to build a cathedral" rather than "I'm laying bricks" point of view. Treat the tools you know as incidental to the job of helping your employer achieve their aims.
I should know better than to press "submit" in that 15 second window after a extra-strong short black macciato... Um, maybe a bit off-topic....
-- Attributed to William Randolph Hearst to a correspondent prior to the Spanish-American War