That's one of the reasons I still use fullscreen text applications to read mail and USENET -- the cyan and green on black combination which I tend to use is very easy on my eyes.:-)
Yup, and same with UNISCOPE/UTS terminals. Local editing on a screen form with the cursor restricted to input fields, a transmit key to send the data to the host, and no network traffic at all until a request is sent.
Both terminals had a lot of smarts built in (a UTS terminal enforce data alignment and alpha/numeric data types on a field-by-field basis all by itself after the initial screen is sent, since the terminal protocol contains field attributes which can specify things like "Left-Justified Numeric", etc.). It's rather nice.
Sounds like they're using Liason and IATA Type B messages?
We used to use the Attachmate UTS emulator's API for UTS connectivity in UNIX environments when I worked at NWA, and we used Type B for just about everything that needed guaranteed delivery (ACARS, WX, even printer and some types of unsolicited CRT traffic).
Now that I'm actually working for SITA I suspect we'd use Liason a lot more internally, and we have a much more diverse messaging infrastructure. 50+ years of connecting to doznes of airlines creates an interesting mess.;-)
I agree that TCP/IP networking wasn't the most common (heck, we had a Novell LAN at my current workplace until the past year or so), but in some business contexts it was quite well known, and common, well before 1994.
Just FWIW, the airline industry still uses them heavily. In a flexible mainframe transaction environment, you can have thousands of different input screens and data requests on a system (usually controlled by a transaction code in the upper left corner), and you can use some fairly flexible security measures to ensure that only certain sign-ons can perform certain types of transactions.
Even the ancient system I worked on five years ago at a major airline (first developed in 1966) allowed you to arbitrily assign a series of mode numbers to each transaction code and to each and every user of the system, and if things didn't match, the transaction didn't work. That sometimes included the location of the terminal as well as the modes assigned to the person's signon. And everything ran inside an isolated transaction sandbox, meaning that direct access to the OS simply didn't exist. Folks running TIP applications were at the mercy of the TIP scheduler.
Add a sophisticated text form-editing environment to the mix, and you end up being able to do quite a bit even though we're talking about 80x24 green screens for the most part.
The disk of things like viruses, etc., depends on a whole array of factors including the hardware and OS being used, the amount of actual "access" a remote end-user has, etc.
There are still some types of applications (like mainframe airline reservation systems) which have never stopped being "green screen" applications (albeit often with an updated GUI or web interface), and some of those can run 100,000's of terminals concurrently and do so worldwide without issues.
My problem isn't with prosecuting folks who pirate software, it's more with the draconian measures that the BSA is willing to take, and the apparently difficult rpocess that a company has to go through to prove that their software is legitimate. Having disks, license keys, and boxes on site apparently isn't enough.
The use of broadband deployment as a measurement would seem to favor those cities where some sort of government monopoly on the communications infrastructure exists. Market-driven companies won't take steps to upgrade (in general) unless they profit from it.
30%: IT spends too much maintaining complex systems and not innovating new ones. Farm out the maintenance.
Complex systems require a certain amount of vertical application expertise by definition, at least if an effective level of support is the desired end result.
Often this expertise takes several *years* to develop effectively.
In many industries, that expertise also tends to be company-specific in nature (and not just industry-specific) because the application software is very tightly coupled to company-specific business rules and procedures. Other companies in the same industry may do similar things using a very different set of procedures, requiring different software (and different expertise).
The time required to grow the required company=specific expertise for effective support often makes the outsourcing of support for those applications impractical unless you spin off your in-house support staff as a separate support company. That sometimes works well.
Basically, I find that any city with a metro/subway/tube/whatever you want to call it is fine for getting around without a car.
That would disqualify most of the cities in the US (DC and NYC are exceptions, not the rule, when it comes to mass transporation).:-)
Some cities have good coverage in the downtown area (Atlanta has MARTA, which covers some of the city), but others like Minneapolis have VERY limited mass transit (light rail is fine as long as you're going between downtown Minneapolis and the airport or Mall of America, but buses are almost worthless unless you're going to/from the core city -- any sideways movement required several bus changes and multiple hours).
I'm not doing this to be rude, or mean, but the simple fact is that if you're overweight you're eating to much. You don't need to exercise to loose weight you need to cut your calorie intake if you're overweight it's because you eat to much.
While probably true in the general case, I'm sure most of us know folks who are exceptions to the above (people who eat tons of junk food and don't exercise and who are still thin as a rail, or people who eat very little and try all kinds of diet plans and who also exercize regularly but who continue to maintain a weight which is far above what is considered "healthy").
There are differences in metabolisms which can impact the effectiveness of weight loss attempts. In my case that isn't true -- I overeat at times and I simply don't exercise enough -- but I've known people in the past who would fit into each of the exceptional categories I described above.
I rememeber Windows 3.1 being an improvement over Windows 3.0, and Windows 3.0 was certainly an improvement over the copy of Windows/286 2.1 I used previously.
Bad wording on the blogger's part, I think...
I thought the "Spam King" was Sanford Wallace?
on
MySpace Sues Spam King
·
· Score: 2, Interesting
I know he's been gone for a long time, but it's weird to see these titles recycled.:-)
I've found over the years that reading about the issues folks are having with Product X in one of the technical newsgroups is often quite worthwhile. It doesn't always cover enterprise stuff, but that isn't normally my area of interest anyway...
The idea itself isn't bad, but the requirement to install a third-party software add-on isn't, especially one which is only available for a few platforms.
I regularly download Firefox updates to my fileserver and then install it on both my wife's box and the several that I maintain. One download, two users, several installations.
And have the game bounce back and forth between the more traditional Elite starship context and maybe an FPS-like interface for wandering around on each starbase. Or planet.
Obviously, anything stored on a computer with a finite amount of memory is going to have a finite limit, but in this case the practical limit is actually quite high.
The day counter is an unsigned 18-bit field (a half-word on 2200-series mainframe architecture), which allows for 262,143 days to be stored just in the day offset (roughly 717.7 years). Assuming we never change the base date at all (which I think starts at January 1, 1967 at this point), the existing counter will because a problem at some point in the year 2684 A.D.
However, as I said, the base year is a parameter in a table which can be updated at any time, and I don't remember the limit of that field off the top of my head. I suspect it's 9999, so we'd be limited to a date sometime in the year 10716 A.D. I don't remember how to get to that parameter screen, either, and the manual is currently locked in my manager's office.:-)
Unfortunate, and certainly finite, but most would say sufficient for most purposes.
Slashdot Mirror
That's one of the reasons I still use fullscreen text applications to read mail and USENET -- the cyan and green on black combination which I tend to use is very easy on my eyes. :-)
Yup, and same with UNISCOPE/UTS terminals. Local editing on a screen form with the cursor restricted to input fields, a transmit key to send the data to the host, and no network traffic at all until a request is sent.
Both terminals had a lot of smarts built in (a UTS terminal enforce data alignment and alpha/numeric data types on a field-by-field basis all by itself after the initial screen is sent, since the terminal protocol contains field attributes which can specify things like "Left-Justified Numeric", etc.). It's rather nice.
Sounds like they're using Liason and IATA Type B messages?
;-)
We used to use the Attachmate UTS emulator's API for UTS connectivity in UNIX environments when I worked at NWA, and we used Type B for just about everything that needed guaranteed delivery (ACARS, WX, even printer and some types of unsolicited CRT traffic).
Now that I'm actually working for SITA I suspect we'd use Liason a lot more internally, and we have a much more diverse messaging infrastructure. 50+ years of connecting to doznes of airlines creates an interesting mess.
I agree that TCP/IP networking wasn't the most common (heck, we had a Novell LAN at my current workplace until the past year or so), but in some business contexts it was quite well known, and common, well before 1994.
Just FWIW, the airline industry still uses them heavily. In a flexible mainframe transaction environment, you can have thousands of different input screens and data requests on a system (usually controlled by a transaction code in the upper left corner), and you can use some fairly flexible security measures to ensure that only certain sign-ons can perform certain types of transactions.
Even the ancient system I worked on five years ago at a major airline (first developed in 1966) allowed you to arbitrily assign a series of mode numbers to each transaction code and to each and every user of the system, and if things didn't match, the transaction didn't work. That sometimes included the location of the terminal as well as the modes assigned to the person's signon. And everything ran inside an isolated transaction sandbox, meaning that direct access to the OS simply didn't exist. Folks running TIP applications were at the mercy of the TIP scheduler.
Add a sophisticated text form-editing environment to the mix, and you end up being able to do quite a bit even though we're talking about 80x24 green screens for the most part.
Argh. C/disk/risk/A (or s/disk/risk/, or whatever).
The disk of things like viruses, etc., depends on a whole array of factors including the hardware and OS being used, the amount of actual "access" a remote end-user has, etc.
There are still some types of applications (like mainframe airline reservation systems) which have never stopped being "green screen" applications (albeit often with an updated GUI or web interface), and some of those can run 100,000's of terminals concurrently and do so worldwide without issues.
What about music? :-(
My problem isn't with prosecuting folks who pirate software, it's more with the draconian measures that the BSA is willing to take, and the apparently difficult rpocess that a company has to go through to prove that their software is legitimate. Having disks, license keys, and boxes on site apparently isn't enough.
Well, OS/2 Warp 3 had it in 1994, Linux certainly did, and our Macs at my workplace running System 7 also did.
What else was there? Our Sun workstations? Oh wait -- they had TCP/IP as well.
The use of broadband deployment as a measurement would seem to favor those cities where some sort of government monopoly on the communications infrastructure exists. Market-driven companies won't take steps to upgrade (in general) unless they profit from it.
If I received a multi-million-dollar severance package like many CEOs appear to receive, you can bet that I'd never work as ANYTHING again. :-)
Complex systems require a certain amount of vertical application expertise by definition, at least if an effective level of support is the desired end result.
Often this expertise takes several *years* to develop effectively.
In many industries, that expertise also tends to be company-specific in nature (and not just industry-specific) because the application software is very tightly coupled to company-specific business rules and procedures. Other companies in the same industry may do similar things using a very different set of procedures, requiring different software (and different expertise).
The time required to grow the required company=specific expertise for effective support often makes the outsourcing of support for those applications impractical unless you spin off your in-house support staff as a separate support company. That sometimes works well.
It's not for lack of trying, believe me... :-(
That would disqualify most of the cities in the US (DC and NYC are exceptions, not the rule, when it comes to mass transporation). :-)
Some cities have good coverage in the downtown area (Atlanta has MARTA, which covers some of the city), but others like Minneapolis have VERY limited mass transit (light rail is fine as long as you're going between downtown Minneapolis and the airport or Mall of America, but buses are almost worthless unless you're going to/from the core city -- any sideways movement required several bus changes and multiple hours).
While probably true in the general case, I'm sure most of us know folks who are exceptions to the above (people who eat tons of junk food and don't exercise and who are still thin as a rail, or people who eat very little and try all kinds of diet plans and who also exercize regularly but who continue to maintain a weight which is far above what is considered "healthy").
There are differences in metabolisms which can impact the effectiveness of weight loss attempts. In my case that isn't true -- I overeat at times and I simply don't exercise enough -- but I've known people in the past who would fit into each of the exceptional categories I described above.
I rememeber Windows 3.1 being an improvement over Windows 3.0, and Windows 3.0 was certainly an improvement over the copy of Windows/286 2.1 I used previously.
Bad wording on the blogger's part, I think...
I know he's been gone for a long time, but it's weird to see these titles recycled. :-)
I've found over the years that reading about the issues folks are having with Product X in one of the technical newsgroups is often quite worthwhile. It doesn't always cover enterprise stuff, but that isn't normally my area of interest anyway...
I know a number of people who don't know enough to install plugins, so your 99% figure is highly suspect. :-)
The idea itself isn't bad, but the requirement to install a third-party software add-on isn't, especially one which is only available for a few platforms.
How about Rescue Raiders using the TA:Spring engine?
:-)
PacMan the FPS. You versus the dots (go get 'em!).
A good modern Pinball Construction Set?
Rocky's Boots?
A modern Stellar 7. I used to play that for hours.
I regularly download Firefox updates to my fileserver and then install it on both my wife's box and the several that I maintain. One download, two users, several installations.
Downloads != users.
And have the game bounce back and forth between the more traditional Elite starship context and maybe an FPS-like interface for wandering around on each starbase. Or planet.
Obviously, anything stored on a computer with a finite amount of memory is going to have a finite limit, but in this case the practical limit is actually quite high.
:-)
The day counter is an unsigned 18-bit field (a half-word on 2200-series mainframe architecture), which allows for 262,143 days to be stored just in the day offset (roughly 717.7 years). Assuming we never change the base date at all (which I think starts at January 1, 1967 at this point), the existing counter will because a problem at some point in the year 2684 A.D.
However, as I said, the base year is a parameter in a table which can be updated at any time, and I don't remember the limit of that field off the top of my head. I suspect it's 9999, so we'd be limited to a date sometime in the year 10716 A.D. I don't remember how to get to that parameter screen, either, and the manual is currently locked in my manager's office.
Unfortunate, and certainly finite, but most would say sufficient for most purposes.