The basic problem here is that ISPs should either act like common carriers and not discriminate based on content, or be held fully accountable for all content they carry and be subject to lawsuits.
This is true- but it is also important to remember that any nonprofit that chooses this approach has to be able to demonstrate that the for-profit entity is tied into the mission and program of the organization in a substantive way- not just an unconnected business which provides revenue.The risk is running afoul of 'unrelated business income tax', and possibly cause a loss of the federal 501(c)(3) exempt status.
Anyone who thinks grants have anything more than a minimal role in nonprofit sustainability does not understand how noprofit businesses work, unless they are supported by a unit of government as an agent for the provision of human services, like Chicago Area Project which gets the bulk of its revenue from state grants.
Nonprofits generally earn the preponderance of their revenue on a continuing basis from donations by individuals and/or organizations/businesses. They work to develop large networks of interested donors by having a properly constituted board of directors- meaning that board members designated as 'money people', whose primary purpose on the board is to assist in fundraising, must meet annual donation requirements- either directly from that board member's pocket, or through the network of pockets that board member is able to access. The combination of a good set of 'money' board members, a savvy development director, events, charged services, grants, and systematic/consistently applied overhead costs all lead to sustainability. Schools and hospitals have an additional tool- they can actually earn the bulk of their revenue from investment income, which other nonprofits are not allowed to do.
Hire veteran COBOLers, retirements won't matter.
on
COBOL Will Outlive Us All
·
· Score: 5, Insightful
It is a bromide perpetrated by ITAA and business groups that we can't find enough programmers to replace the ones who are retiring.
The simple truth is that no one wants to PAY what people are worth, and there is rampant age discrimination:
Be willing to hire, retrain, or do whatever it takes to employ people over 35 and this so-called problem will be shown to be the chimera that it really is.
I would suggest you learn about what are known as 501(c)(12) telecommunications cooperatives. One specific example would be www.rric.net It would also be good for you to consult the IRS information on this kind of nonprofit organization.
It is sad to have to say this, but color management as required by graphic arts applications is very poorly implemented under Linux. There is no universally agreed-upon CMM(color management module), and applications do not uniformly implement and respect color management. Also, creating and maintaining ICC profiles under Linux is a difficult proposition at best. The best profile generation package, Argyll, is an open source command line product that is unable to work directly with scanning tables like the i1io, Barbieri, or Colorpartner units. Argyll's UI approach is not anywhere as convenient as products like profilemaker, monacoprofiler, or i1profiler. For those who need to use a RIP, there is exactly one offering available- Caldera.
I wish Linux could support graphic arts and printing for professional printers as well as Win and OS/X.
Sadly the PC world has unitl recently ignored yet another lesson from mainframes- logical partitioning.
The concept is a minimal bare-metal hypervisor which in mainframes is built into the hardware and is integrated with a robust set of configuration tools. It's nice to see at least a shadow of this concept being implemented in something.
Actually, the process Kodachrome uses to produce the color is still based on the fundamental instability which plagues all chromogenic systems- even though the dye coupler is not in the emulsion(as would be the case with Kodacolor and Ektachrome), the fact is that the process is still the same. A dye coupler combines with developing agent by-products in proportion to the amount of underlying silver that is developed. I've always wondered how Kodachrome achieved greater archival permanence; maybe it is because the coupler/developing agent byproduct reaction happens only in processing and the dye coupler does not have a chance to become spoiled while unused sitting in an emulsion.
I would like to know if you are able to color manage your monitor with an appropriate ICC profile, and if so, how you get this profile properly applied to the virtual display?
None of the virtualization environments allow for applying color profiles to the virtual graphics display.
As a photographer, you will be concerned with proper color management of your monitor, and so you need a base environment which properly supports this. That base environment regrettably needs to be a Windows desktop or server operating system.
For well over 30 years, airline reservation, hotel reservation, and other high volume transaction processing(HVTP) systems that are mainframe-based have not used SQL in the core transaction processing system. They use either the built-in key/value subsystem of TPF/ZTPF, or a slightly more sophisticated subsystem known as TPFDB. Using facilities similar to zOS, failover and recovery happen in record time should it be necessary. This successful real-world system and approach deserves the attention of those who would like to learn how this stuff really works.
It's always funny to read things written by people who obviously are inexperienced with high volume transaction processing in the mainframe environment. The systems behind airline, rail, and hotel reservations as well as emergency response messaging often are built on IBM mainframes using TPF/ZTPF as the operating system and TPFDB(formerly known as ACPDB) as the underlying database. If someone would take the time to study TPFDB, they would notice its nonrelational character, as well as some interesting similarities to what the Cassandra developers unknowingly chose to do. By the way, these systems are happily handling 10K-12K transactions per second without bunny farm racks of servers.
Sometimes progress is not always about what will be done, but understanding the benefits of older things that have been done.
You are essentially talking about what government does when they float a bond to create infrastructure, but instead your concept is a voluntary association of homeowners who agree to enter into an agreement to loan money to the phone company. You could more effectively do this by having the residents form a 501(c)(12) telecommunications cooperative and use that cooperative entity to negotiate with the phone company to fiber up your block, for example. You are still doing the finance, but you do it under a recognized legal entity.
Of course, the best thing would be for municipalities to take over telecommunications pipes to the home as a public service like water, sewers, and roads, but that would require us to remind ourselves of how government is not evil and exists to serve the people. In this kind of scenario, telecommunication companies could become hired help under contract to government to provide maintenance, content, and other things.
It used to be that the conflict of interest was resolved by enabling those who agreed only to provide the pipe to be covered for liability by a concept known as 'common carrier'. If you were simply providing the pipe, and no content, you couldn't be held liable for what went through the pipe. Essentially through corruption and a lack of public awareness, we are not properly enforcing common carrier law through lawsuits against content providers who try to have their cake and eat it too.
Unfortunately, due to the corruption of the public sense and understanding by an MBA-dominated concept of service, many people are under the misunderstanding that the fiscal goal of public service or nonprofit organizations is to fiscally produce excess revenue over expenses, otherwise known as profit. The pre-MBA-dominated understanding of the fiscal goal of public service and nonprofit organizations is that they are to produce the maximum utilization by the public of their programs and services at a balanced budget where revenue and expenses are equal.
Why do we let idiots with MBA degrees tell people in government and public service how to manage their finances and operations using fiscal principles that don't apply?
No revisit is necessary after 8 years. The structural issues with linux on the mainframe are exactly that- structural. How aboout this- go into real mainframe shops in mainframe-committed businesses like insurance, transit reservations, banking, and so on, and find out what the core business transaction systems run on. It won't be linux, and for manifold good reasons, mostly related to RAS. Linux has nothing even remotely resembling the abilities in Parallel Sysplex(zOS), but there's no need to escalate to that- even the most basic device error recovery management in a mainframe operating system is better handled than in Linux.
And by the way, the assumption that with the progression of years comes inherent improvement in technology is by no means a certainty, especially in computing. Ask someone who knows anything about Keykos whether today's operating systems have incorporated even half the concepts they got right. Oh wait- let me not forget- Keykos and many other earlier operating systems aren't covered in a typical CS operating systems course, but that must be because the 'experts' have deemed them irrelevant. The same 'experts' ignore TPF/zTPF as well, which have been happily doing transit reservation systems for over 40 years. So much for progress inherent in the march of years.
There are a number of factors which go into this consideration of Linux on the mainframe. I must admit it was really cool when I first learned of it, having had an MP3000 to myself at an IBM training facilty to learn how to bring up VM/ESA and Linux/390(2001). Then I realized a few things like:
1. Linux cannot take advantage of the advantages of channel-based disk i/o, because it uses Unix i/o approaches which can never be as efficient as the traditional mainframe-based approaches. No one has shown me any evidence that Linux does anything particularly intelligent in its channel program construction and management. Linux assures that IBM can happily sell lots of IFL or general purpose CPUs which are necessary to compensate for this inefficient use of mainframe resources.
2. Managing workloads under zVM can be great and is extremely well refined, but this requires zVM-specific skills which supposedly no one wants to pay for.
3. For transaction-based work, it's hard to beat TPF/zTPF, but unfortunately that requires some real mainframe skill to implement. And regrettably, zTPF requires Linux and zOS because IBM refuses to convert the programs running on zOS to run on Linux instead. Since TPF/zTPF and zOS both involve onerous monthly licensing charges based on capacity, it's no wonder that TPF/zTPF languish in relative obscurity.
I can't understand why anyone is surprised that people trained in computer science are ill equipped to develop business software.
How many computer science graduates typically have the slightest clue what accounting is, or how it works?
How many computer science undergraduate programs deal with the customary and legal environment of business?
How many computer science programs deal with the realities of designing and maintaining a datacenter, in theory and/or practice?
Computer science is a theoretical self-serving discipline designed to produce more computer science graduate students. Anyone who learns practical, appropriate, and customary reality does so more often despite rather than because of their education.
Unfortunately, the respondent does not understand the workload context for which the mainframe is optimal when a comment like "Hey, you tell it to Google" is made.
On a TCO basis, when the workload is primarily i/o bound with small to modest computation required per unit of work, the mainframe will excel. Compute intensive applications like Google search are not best implemented in a mainframe for this reason. Neither is scientific computation, nor multimedia, among other things.
The concepts of workload and workload management are crucial to understanding the appropriate application of mainframe technology.
As many slashdot readers may not have familiarity with mainframes, this may seem obscure, but nevertheless worthwhile.
In the IBM mainframe world, the clustering system known as parallel sysplex involves a rather interesting use of what would otherwise be a general purpose computing engine as something that IBM calls a coupling facility. It enables mainframe-based software like DB2 to coordinate the use of system-wide locking, caching, and list processing at a much higher level of performance than if left to conventional software.
SAP has what was at one time called SAPDB, and is now called MaxDB, which has an interesting mode of operation known as LiveCache. By the way, as an aside, SAP refuses to document use of LiveCache so that open source users might actually explore its possibilities. LiveCache is used by SAP's Advanced Planning and Optimizer subsystem of their ERP software to cache objects from multiple sources so as to improve performance of the package overall.
A careful study of the IBM coupling facility patents and SAP's design and use of LiveCache might reveal some interesting similarities. Of course, SAP may very well have an appropriate agreement or licensing arrangement with IBM for this, and that would be all well and good. I hope there might be some way to find out whether this is the case, should IBM possibly choose to pursue this.
As another interesting anecdote, Oracle recently purchased an in-memory database software company whose product is also being used in a similar performance-enhancing multi-system caching and coordination arrangement. This of course is being used to enhance Oracle database performance, in a manner which again seems astonishingly similar to the IBM mainframe coupling facility. Oracle might also have an agreement or arrangement of some kind with IBM to deal with this, but this is unknown.
We all must wonder about this, at least just a little.
You all need to get the message about what IPDR really is- it is a means of altering the internet protocol to enable per service and per packet charging beyond anyone's current imaginations.
I'm sure you can figure out the implications-
no more flat monthly rates nickling and diming to death for everything
Slashdot Mirror
The basic problem here is that ISPs should either act like common carriers and not discriminate based on content, or be held fully accountable for all content they carry and be subject to lawsuits.
This is true- but it is also important to remember that any nonprofit that chooses this approach has to be able to demonstrate that the for-profit entity is tied into the mission and program of the organization in a substantive way- not just an unconnected business which provides revenue.The risk is running afoul of 'unrelated business income tax', and possibly cause a loss of the federal 501(c)(3) exempt status.
Anyone who thinks grants have anything more than a minimal role in nonprofit sustainability does not understand how noprofit businesses work, unless they are supported by a unit of government as an agent for the provision of human services, like Chicago Area Project which gets the bulk of its revenue from state grants.
Nonprofits generally earn the preponderance of their revenue on a continuing basis from donations by individuals and/or organizations/businesses. They work to develop large networks of interested donors by having a properly constituted board of directors- meaning that board members designated as 'money people', whose primary purpose on the board is to assist in fundraising, must meet annual donation requirements- either directly from that board member's pocket, or through the network of pockets that board member is able to access. The combination of a good set of 'money' board members, a savvy development director, events, charged services, grants, and systematic/consistently applied overhead costs all lead to sustainability. Schools and hospitals have an additional tool- they can actually earn the bulk of their revenue from investment income, which other nonprofits are not allowed to do.
It is a bromide perpetrated by ITAA and business groups that we can't find enough programmers to replace the ones who are retiring.
The simple truth is that no one wants to PAY what people are worth, and there is rampant age discrimination:
http://www.itbusinessedge.com/cm/blogs/tennant/yes-age-discrimination-is-worse-in-it-than-in-other-fields/?cs=38549
Be willing to hire, retrain, or do whatever it takes to employ people over 35 and this so-called problem will be
shown to be the chimera that it really is.
I would suggest you learn about what are known as 501(c)(12) telecommunications cooperatives. One specific example would be www.rric.net
It would also be good for you to consult the IRS information on this kind of nonprofit organization.
It is sad to have to say this, but color management as required by graphic arts applications is very poorly implemented under Linux. There is no universally agreed-upon CMM(color management module), and applications do not uniformly implement and respect color management. Also, creating and maintaining ICC profiles under Linux is a difficult proposition at best. The best profile generation package, Argyll, is an open source command line product that is unable to work directly with scanning tables like the i1io, Barbieri, or Colorpartner units. Argyll's UI approach is not anywhere as convenient as products like profilemaker, monacoprofiler, or i1profiler. For those who need to use a RIP, there is exactly one offering available- Caldera.
I wish Linux could support graphic arts and printing for professional printers as well as Win and OS/X.
Sadly the PC world has unitl recently ignored yet another lesson from mainframes- logical partitioning.
The concept is a minimal bare-metal hypervisor which in mainframes is built into the hardware and is integrated with a robust set of configuration tools. It's nice to see at least a shadow of this concept being implemented in something.
Actually, the process Kodachrome uses to produce the color is still based on the fundamental instability which plagues all chromogenic systems- even though the dye coupler is not in the emulsion(as would be the case with Kodacolor and Ektachrome), the fact is that the process is still the same. A dye coupler combines with developing agent by-products in proportion to the amount of underlying silver that is developed. I've always wondered how Kodachrome achieved greater archival permanence; maybe it is because the coupler/developing agent byproduct reaction happens only in processing and the dye coupler does not have a chance to become spoiled while unused sitting in an emulsion.
I would like to know if you are able to color manage your monitor with an appropriate
ICC profile, and if so, how you get this profile properly applied to the virtual display?
None of the virtualization environments allow for applying color profiles to the virtual graphics display.
As a photographer, you will be concerned with proper color management of your monitor, and so you
need a base environment which properly supports this. That base environment regrettably needs to be
a Windows desktop or server operating system.
For well over 30 years, airline reservation, hotel reservation, and other high volume transaction processing(HVTP) systems that are mainframe-based have not used SQL in the core transaction processing system. They use either the built-in key/value subsystem of TPF/ZTPF, or a slightly more sophisticated subsystem known as TPFDB. Using facilities similar to zOS, failover and recovery happen in record time should it be necessary. This successful real-world system and approach deserves the attention of those who would like to learn how this stuff really works.
It's always funny to read things written by people who obviously are inexperienced with high volume transaction processing in the mainframe environment. The systems behind airline, rail, and hotel reservations as well as emergency response messaging often are built on IBM mainframes using TPF/ZTPF as the operating system and
TPFDB(formerly known as ACPDB) as the underlying database. If someone would take the time to study TPFDB, they would notice its nonrelational character, as well as some interesting similarities to what the Cassandra developers unknowingly chose to do. By the way, these systems are happily handling 10K-12K transactions per second without bunny farm racks of servers.
Sometimes progress is not always about what will be done, but understanding the benefits of older things that have been done.
You are essentially talking about what government does when they float a bond to create infrastructure, but instead your concept is a voluntary association of homeowners who agree to enter into an agreement to loan money to the phone company. You could more effectively do this by having the residents form a 501(c)(12) telecommunications cooperative and use that cooperative entity to negotiate with the phone company to fiber up your block, for example. You are still doing the finance, but you do it under a recognized legal entity.
Of course, the best thing would be for municipalities to take over telecommunications pipes to the home as a public service like water, sewers, and roads, but that would require us to remind ourselves of how government is not evil and exists to serve the people. In this kind of scenario, telecommunication companies could become hired help under contract to government to provide maintenance, content, and other things.
It used to be that the conflict of interest was resolved by enabling those who agreed only to provide the pipe to be covered for liability by a concept known as 'common carrier'. If you were simply providing the pipe, and no content, you couldn't be held liable for what went through the pipe. Essentially through corruption and a lack of public awareness, we are not properly enforcing common carrier law through lawsuits against content providers who try to have their cake and eat it too.
Unfortunately, due to the corruption of the public sense and understanding by an MBA-dominated concept of service, many people are under the misunderstanding that the fiscal goal of public service or nonprofit organizations is to fiscally produce excess revenue over expenses, otherwise known as profit. The pre-MBA-dominated understanding of the fiscal goal of public service and nonprofit organizations is that they are to produce the maximum utilization by the public of their programs and services at a balanced budget where revenue and expenses are equal.
Why do we let idiots with MBA degrees tell people in government and public service how to manage their finances and operations using fiscal principles that don't apply?
No revisit is necessary after 8 years. The structural issues with linux on the mainframe are exactly that- structural. How aboout this- go into real mainframe shops in mainframe-committed businesses like insurance, transit reservations, banking, and so on, and find out what the core business transaction systems run on. It won't be linux, and for manifold good reasons, mostly related to RAS. Linux has nothing even remotely resembling the abilities in Parallel Sysplex(zOS), but there's no need to escalate to that- even the most basic device error recovery management in a mainframe operating system is better handled than in Linux.
And by the way, the assumption that with the progression of years comes inherent improvement in technology is by no means a certainty, especially in computing. Ask someone who knows anything about Keykos whether today's operating systems have incorporated even half the concepts they got right. Oh wait- let me not forget- Keykos and many other earlier operating systems aren't covered in a typical CS operating systems course, but that must be because the 'experts' have deemed them irrelevant. The same 'experts' ignore TPF/zTPF as well, which have been happily doing transit reservation systems for over 40 years. So much for progress inherent in the march of years.
There are a number of factors which go into this consideration of Linux on the mainframe. I must admit it was really cool when I first learned of it, having had an MP3000 to myself at an IBM training facilty to learn how to bring up VM/ESA and Linux/390(2001). Then I realized a few things like:
1. Linux cannot take advantage of the advantages of channel-based disk i/o, because it uses Unix i/o approaches which can never be as efficient as the traditional mainframe-based approaches. No one has shown me any evidence that Linux does anything particularly intelligent in its channel program construction and management. Linux assures that IBM can happily sell lots of IFL or general purpose CPUs which are necessary to compensate for this inefficient use of
mainframe resources.
2. Managing workloads under zVM can be great and is extremely well refined, but this requires zVM-specific skills which supposedly no one wants to pay for.
3. For transaction-based work, it's hard to beat TPF/zTPF, but unfortunately that requires some real mainframe skill to implement. And regrettably, zTPF requires Linux and zOS because IBM refuses to convert the programs running on zOS to run on Linux instead. Since TPF/zTPF and zOS both involve onerous monthly licensing charges based on capacity, it's no wonder that TPF/zTPF languish in relative obscurity.
SAP closed-sourced SAPDB/MaxDB.
They never provided anything resembling a decent explanation as to why.
I can't understand why anyone is surprised that people trained in computer science are ill equipped to develop
business software.
How many computer science graduates typically have the slightest clue what accounting is, or how it works?
How many computer science undergraduate programs deal with the customary and legal environment of
business?
How many computer science programs deal with the realities of designing and maintaining a datacenter,
in theory and/or practice?
Computer science is a theoretical self-serving discipline designed to produce more computer science
graduate students. Anyone who learns practical, appropriate, and customary reality does so more
often despite rather than because of their education.
Time for a radical reassessment.
Unfortunately, the respondent does not understand the workload
context for which the mainframe is optimal when a comment like
"Hey, you tell it to Google" is made.
On a TCO basis, when the workload is primarily i/o bound
with small to modest computation required per unit of work,
the mainframe will excel. Compute intensive applications
like Google search are not best implemented in a mainframe
for this reason. Neither is scientific computation, nor
multimedia, among other things.
The concepts of workload and workload management are
crucial to understanding the appropriate application
of mainframe technology.
www.strassmann.com has some of the best material around for
considering questions like this.
I have not used these products, so I cannot personally vouch
for them:
www.ncomputing.com
They offer a solution that sounds like what you want.
As many slashdot readers may not have familiarity with
mainframes, this may seem obscure, but nevertheless
worthwhile.
In the IBM mainframe world, the clustering system
known as parallel sysplex involves a rather interesting
use of what would otherwise be a general purpose
computing engine as something that IBM calls a
coupling facility. It enables mainframe-based
software like DB2 to coordinate the use of system-wide
locking, caching, and list processing at a much
higher level of performance than if left to
conventional software.
SAP has what was at one time called SAPDB, and is now
called MaxDB, which has an interesting mode of operation
known as LiveCache. By the way, as an aside, SAP refuses
to document use of LiveCache so that open source users
might actually explore its possibilities. LiveCache is
used by SAP's Advanced Planning and Optimizer subsystem
of their ERP software to cache objects from multiple
sources so as to improve performance of the package
overall.
A careful study of the IBM coupling facility patents
and SAP's design and use of LiveCache might reveal
some interesting similarities. Of course, SAP may
very well have an appropriate agreement or licensing
arrangement with IBM for this, and that would be all
well and good. I hope there might be some way to find
out whether this is the case, should IBM possibly
choose to pursue this.
As another interesting anecdote, Oracle recently
purchased an in-memory database software company
whose product is also being used in a similar
performance-enhancing multi-system caching and
coordination arrangement. This of course is being
used to enhance Oracle database performance, in a
manner which again seems astonishingly similar to
the IBM mainframe coupling facility. Oracle might
also have an agreement or arrangement of some kind
with IBM to deal with this, but this is unknown.
We all must wonder about this, at least just a
little.
You all need to get the message about what
IPDR really is- it is a means of altering
the internet protocol to enable per service
and per packet charging beyond anyone's current
imaginations.
I'm sure you can figure out the implications-
no more flat monthly rates
nickling and diming to death for everything
Need I say more?
This patent is outrageous and unjustified.
DEC's VAX-11 series had this feature in the
1980's. IBM's mainframes have had this
feature for at least 20 years.
It is a wonder how the patent office can
remain ignorant of such clear and obvious
prior art.