56. (1) The Minister may prescribe minimum standards or prohibitions in respect of-- (a) the general management of critical databases; (b) access to, transfer and control of critical databases; (c) infrastructural or procedural rules and requirements for securing the integrity and authenticity of critical data; (d) procedures and technological methods to be used in the storage or archiving of critical databases; (e) disaster recovery plans in the event of loss of critical databases or parts thereof; and (f) any other matter required for the adequate protection, management and control of critical databases.
Actually there is a significant amount of research into the phenomena which sees people lose or relax social and/or moral control when given anonymity.
The opportunity to vent destructive behaviour otherwise unacceptable in society is a coping mechanism employed by some people. It is often done in a (socially) harmless manner - yelling in your own back yard, hitting walls, going to gym - but occaionally people go "over the edge".
Anonymity brings the edge closer: it seems that people are just naturally more destructive when they cannot be held accountable.
At the core of the whole problem is that a society cannot exist with true anonymity. Society requires the ability to identify individuals who are acting against society.
Just FYI: The FONT tag, which is at the center of his rant, IS a standard. Unlike CSS, its going to work properly on almost all browsers. Unlike Hx tags, it doesn't impose formatting on itself or surrounding text - something even CSS isn't great at controlling.
Take a look at David Baron's CSS test results - they are mainly for 2000/2001 browsers, but that includes IE5 and 5.5 which are the most common browsers on the Internet today. It reveals a mass of buggy, unsupported, non-compilant or incompatible implementations of CSS.
Now go to About.com's web design compatibility page and get an idea of the incompatibilities in newer standards between browsers. The result is quite obvious: using CSS is NOT a route to gaining compatibility and avoiding hacks - more than likely its going to involve additional hacks and even further limit browser support.
Coding to de juro standards is useless if the standards aren't properly supported. People have more success following de facto standards, which is why so much of the web is IE-centric.
As I noted in my post, my suggestions may be totally unsuitable for the application - but then there was little information given about the nature of use that is expected. I'm glad to hear an opinion from someone experienced with the other end of the scale.
In my (limited) dealings with data warehousing systems, performance has been a non-issue. These systems have mostly held historical data for occasional retrieval. Often the (in)efficiency of the database system has been the bottleneck. We're talking 10 to 50 TPS on simple queries or blocks or data.
As opposed to the solutions offered by today's high end vendors, RAID takes on its true meaning in this sort of slower-moving-data system. Commodity hardware means less stability, but the warehouse is not a mission-critical system (it can take occasional, short outages). On the other hand it is cheap and easy to replace.
I am not an expert in this field, but Google was willing to tell me lots.
RaidWeb sells rack mountable RAID units that take IDE drives and have SCSI or fibre connectivity. A 12-bay 4U SCSI (with 12x 120Gb IDE drives) system comes in at just under $8000, giving over 1Tb fault tolerant storage. There are several other companies that have units like this.
Rackmount Solutions sells rackmount cabinets. A 44U cabinet with fans, doors, etc. will come in at around $3000.
In theory, a single cabinet could house 11Tb of data, and cost around $91000. This still doesn't consider cabling, cooling, power distribution, networking, a proper server room (air con, false floor for cables, access control), and in all likelihood one or more controlling servers.
More practically, depending on how they are going to make this data accessible, you could be looking at 9 raid units per cabinet plus 3 2U servers and a switch in the remaining space. Each server can support multiple SCSI cards and gigabyte networking. Such rackmount computers will set you back in the region of $6000 (incl. network and SCSI adapters, excl. software).
So you can call it $100,000 for 9 Tb storage... $600,000 for 54Tb. That doesn't answer the management software question, and may not be a suitable solution. But it sure is a lot cheaper than $20 mil;)
Too many people are under the impression that implementing a clone is not an infringement of Copyright. Mistake. Copyright doesn't just cover a work, it covers derivative works too. Take the functionality and interface, and you're creating a derivative.
I haven't used either product, so I'm not going to state that they are similar. Clearly Apple thinks so, and a number of users on this and other forums think so as well. The developer's response also makes it clear they were out to achieve the same ease of use - which often comes down to interface design (functionality wise, not necessarily look and feel).
Software design, much like the plot of a book, is protected by Copyright. Interface design, much like the cover of a book, is too. Create a new plot or cover art from scratch, which is different to the original but uses conceptual elements from it, is not a violation of Copyright. It can be a fine line at times.
The article very definately uses the words "detect" (light behind) and "generate" (image in front). This implies it is not some passthrough technology (fiber, etc), but an electronic record and recreation.
If this "clock" could live up to its claims, there are three (possibly more) far more interesting applications that must be considered:
Holographic photography: the photoreceptors on the back can apparently sense the intensity, colour and trajectory. They can also do this without a lens. Impressive.
Holographic projection / 3D TV: the light emitters on the front can recreate the image behind the object. In order to do this with enough accuracy to clock an object, they have to recreate the trajectory of the light; failing this they have a 2D image which will be noticable as soon as the viewer moves.
Realistic looking TV: apart from the 2D/3D problem, TV just doesn't look real because it is poor at depecting matt textures. A glowing, glossy area within your field of vision would certainly attract your attention, even if it fitted into the background.
Given that researchers would be coining it from more down-to-earth inventions like these, I can't really see that the technology - as described - exists or is being developed.
Creators of remote controls could learn a lot from a simple philosophy behind the success of Windows: Point And Click.
A laser pointer (so you have feedback about where you are pointing) with 6 buttons which have common meanings to household objects could control most of the functions that remote controls are concerned with:
TV: up/down channel and volume
VCR/DVD: up/down channel and volume, play/stop
Lights/Heater: on/off, brighten/dim
...and so on. You don't get to program your VCR (timer record, tuning, etc), but you get the important functionality that you want access to remotely (for the average non-couch-potato). The other drawback is that elderly or disabled people may find it more difficult to have to point (assumedly with some degree of accuracy).
With a bit of additional logic, you can add a minimal LCD display so up/down scrolls through the control options, and left/right manipulates them.
Not even vaguely - this is a clear generalisation. I have no experience with AS/400. However, in my expierience, there is often a reluctance to move to new technologies, and the justification is often to cite them as "immature" and "unproven", whether this is or it not the fact.
I would contend that Linux as an operating system - not all of the junk on top, just the basics - is a proven, stable and reliable system. It runs a significant number of high-uptime, high-volume hosts on the Internet, and has the support of three major vendors of top-end hardware (Sun, HP and IBM).
On the other hand, I firmly believe that if a system works, and does what it is needed to do, don't screw with it. This is, however, completely at odds with the sales strategies of most IT companies.
I am surprised that as an "IBM business partner" the article's author hasn't consulted IBM on how THEY are intending to push Linux to their customers.
One person's mature standard is another's legacy nightmare.
Re:Christianity (off-topic)
on
Ask Larry Wall
·
· Score: 1
As a non-christian, perhaps I can offer some enlightenment. To begin with, I do no believe in a single all-powerful being. I see no evidence of such a being, and I feel no need to believe in a higher power. On the other hand I do not dismiss the possibility of the existance of such a being - I see no evidence of that either. In short, I am agnostic.
Were I to believe in a higher power, it would not be the christian god, and certainly not as portrayed by the various modern demoniations. My reasons are quite simple:
In my experience, most (but not all) churches work using scare tactics to gather followers. Whether they take the direct "you will burn in hell" route, or the indirect "but what if you're wrong - at least if you believe you have nothing to lose" route, it amounts to the same thing: an attempt to use fear to influence your decision. A more common name for this is terrorism.
Nearly all christians I have met are prepared to use their religion only as it suits them. "Love thy neighbour" so long as he is like you, otherwise smite him. Selectively quote the bible to support your view at the time - remember that the bible has been used to support oppression of other religions, women, black people and many other groups. Selective reading of the old testament in particular is behind a lot of discriminatory violence.
The church uses the bible extensively to attempt to control the morality not only of its followers, but of all individuals. As a graduate of psychology, I am appauled by the amount of damage that comes from constant bombardment with ideas like sex being unclean (at least some churches now praise sex as being great - within marriage). Even worse, the catholic obsession (in particular) of avoiding condoms. You may die from AIDS, but at least you didn't use a condom so you won't go to hell.
Much of the church's morality it derived from letters and books of man included in the bible, which do not accurately reflect gods intentions. There ideas have no place in modern society. Christians cling to the ten commandments, but ignore the rules that are laid down in the pages which follow them. Have you had your mildewed leather clothing ritually cleaned by a priest?
My greatest concern about christianity however, is forgiveness. What a wonderful concept. god in his magnificence will forgive you for anything when you sincerely ask for it. Meanwhile, back on planet earth, there are very real consequences for your actions which affect other people.
Too many christians use divine forgiveness as a safety net for their mistakes. Its a great way to avoid the whole psychological problem of a conscience - dump the whole problem on god's doorstep, and he's says "there there, that's ok".
It works wonderfully, until you're on the receiving end of whatever evil was done. Forgiveness doesn't undo fraud, theft, murder, or a billion other crimes. But in a christian society it does make the courts take a more lenient view, despite this being unconstitutional in most of the world.
To be fair, all of these are weaknesses of people, and the organisations that support the religion. I am avoiding the inconsistencies of the religion itself (something that I would have assumed would get on the nerves of geeks more than anything else), not to mention the number of conflicts or murders in the modern and medi-eval worlds that have been in the name of this religion.
If I tell you that BASIC is better than Perl, you will probably laugh. But BASIC has a 38 year history, is supported by the world's largest software company, and used by over 8 million developers worldwide. Perl is 15 years old and has somewhere over 1 million developers. The popularity of BASIC leads to misinformation and ridicule of Perl.
It has to be remembered that Use Cases are customer-centric. They are intended as a semi-formal communication medium which can be understood by customers, analysts, designers and developers.
As such, a system which realises a Use Case may look nothing like the Use Case.
On the other hand, an Object Oriented application is often best designed to mimic the "real world", so your objects and methods tend to drop straight out of a use case.
The usual technique is to take your annotated UML diagrams and pick out the nouns and verbs for each Case, filter them down to a minimal set, and those are (more or less) your objects and methods.
This still involves recapturing though, but this is unavoidable. It is dangerous to think in objects at an analysis level - you tend to make invalid assumptions without even realising it. e.g. A developer is a salaries employee and a cleaner is a wage earning employee. Now, where do you put the contact developer...?
Because you can't capture the objects along with the requirements, you must identify object candidates from the requirements, and determine a suitable design in which they will interact correctly according to the actions/verbs/messages indicated by the requirements.
Then you have to consider everything that the users won't like, the managers will add because it may be useful, and the beancounters will strip. Ew, bad image.
UML is a descriptive language for the entire software process. It crosses domains for which there are no direct mappings... and if there were, customers would be putting in Use Cases and getting out software, with MicroRational/RationalSoft Inc. in between.
The SMTP protocol includes two 3xx response codes; one is "address not local, forward to remote@address" (client agent must handle forwarding), the other is "address not local, will forward to remote@address" (server will do the forwarding).
You are assuming the training is aimed only at programmers and for the purpose of teaching programming. This is seldom the case - most often training is used to promote a programmer's skills to include design knowledge, or management.
Where the object is to teach programming, the result is often shocking. Experienced C/C++ developers regularly come out of courses saying "Hey, I had no IDEA it worked like that".
Many developers take a "know one, know 'em all" approach to languages, without understanding that every language has its own unique way in which it is best applied. For all their syntactical similarity, Java and C++ are worlds apart in the way they should be used, for example, algorithms which are efficient in one are dogs in the other.
I have never been on a training course where I have not learned some useful piece of information. Even a presentation of the Thinking in Java course (after I had read the book and had 5 years of experience with Java) provided some insights which proved useful during project implementation.
On the other hand, I have never met someone who can be an "expert" on a language in one week. There is a lot more to language than syntax, and if you believe otherwise, you are seriously deluding yourself.
After an argument with higher calculus I dropped out of university, got a job, and later picked up my studies part-time by correspondence - the traditional mail, books and paper kind.
If you are a good learner and/or have time to dedicate to your studies (a couple of hours a day, preferably), I think this is an excellent way to go.
I completed my degree through UNISA (the University of South Africa). They offer a number of excellent courses in all faculties, including postgraduate studies; have over 110,000 students, are recognised worldwide and examination centers in many countries.
Some of the faculties are most suited to international students than others. The computer science department, for example, accepts most tutorial submissions online. I see their home page has links for online registration and payment as well.
UNISA will allow you to transfer credits from recognised institutions (up to a maximum of half the total needed for your degree).
This is a bit of a shameless plug, but if you're going to get a qualification, it is worth getting it from a known, recognised and respected institution.
I think you'll find that this is the intention behind a law to force software to provide warrantees;)
Just FYI: My dad runs his home PC on Windows 95. Some of his friends use Windows 3.1. They don't suffer continual failures, etc, that we usually attribute to these systems. When you aren't pushing the OS, and are running reliable applications on top of it, you can expect many years of good service, even from w95. Sadly, it is hardware failures and the lack of w95 driver support on new peripherals that are forcing him to consider a sidegrade to a newer version of windows.
I assume you are aware that a number of higher end (umm... luxury;) ) vehicles these days effectively DO have welded hoods. The maintainable parts of the engine are locked away in compartments which require special tools to access - the type you can only get hold of it you agree to a dealer contract with the manufacturer.
Despite this, there are still millions of people who drive BMWs, and Windows.
For academic instruction XML is not a bad idea at all. I believe it is a bad implementation, not a bad concept. It is conceptually ideal for many forms of communication, and has benefits in academia: it is well studied, resources are available, and it is easy to view the protocol in action and dissect every step (without resorting to deciphering binary packets).
I'm sorry I didn't present the second part of my argument clearly. The problem of ignoring parameters is more serious when you can't upgrade everything simultaneously, and especially when you upgrade the client first.
For example: a method is upgraded to take an additional parameter "skew" (it just adds that number to the return value). The client happily calls the server, not knowing that the server is running an older version of the software, which ignores the "skew" parameter, and returns the wrong result.
Careful schema control, and having the client identify its schema/API version to the server is a good way to handle this, but developers are notoriously bad at meticulous API versioning (which falls into the category of tasks I referred to as configuration management).
The best practice is to clearly separate the two versions of the API -- introduce completely new functions when you need to add parameters, don't simply use what appears to be overloading (but isn't). An alternative practice is to use inheritence to make v2 of the API a subclass of v1, with additional (possibly overloaded) functions.
Essentially, you need to treat the distributed environment no differently from objects on a local machine. If you add parameters to a method, you must provide a new, separate, overloaded method. Changing the existing method would break existing code which uses it - so you don't do it. If it makes sense to do so, the old implementation can be changed to call the new method with some default parameters - but this is not always the case.
As a rule, ignoring data is a bad thing. It its not used, it probably shouldn't be there... and if it's there, it should probably be used;)
AAMOI, the Visa 3D-Secure specifications permit certain communication end-points to ignore certain fields for forwards compatibility, but within a strict framework: some servers and/or messages cannot ignore fields, and any field of any message can be marked such that the recipient MUST understand the field, or force the transaction to fail.
But, it must also be understood that the Visa framework does not operate using SOAP (or a system where the target function is indicated within the request); updating legacy systems to talk to new URLs (possibly multiple URLs, to support multiple versions) because an API has changed is not an option, and the framework has been designed to operate within the constraints of the current web services that offer e-commerce.
Java has no assembler level instructions to do port IO. It also doesn't provide you with direct memory access - which goes beyond alloc/free as you need to control the descriptor tables which define memory protection. Then you have the problem of handling interrupts (not only hooking them, but masking and unmasking, which on most architectures as CPU instructions), etc.
Without JNI, you can't hope to achieve any of this. C/C++ allows you to "drop down" to asm at any point, in such a way that the asm is compiled into the final object code. Java has no such functionality.
It *may* be theoretically possible to create a Java kernel on a system built specifically for that purpose - by allowing hardware control (IO, memory protection, interrupts) via memory mapping; but I still think you'll find you need to run a microcode interpretter on the CPU to handle garbage collection (amongst others), and a class to provide direct memory access to the mapped regions -- neither of which could be expressed in "pure" Java.
You know the problem with the world? There are too many developers out there who will read your first paragraph and say "That is such a cool idea - I'm going to do it right now!"...
There are several existing standards for the interchange of information between disparate systems, and that includes languages. And a number of those are complete remote procedure call systems.
ASN.1 has been around since 1984 (or somewhere close), and is a terse binary protocol build for this sort of communication. It is used extensively in the telecoms industry and is supported in almost every language. It is standard, well known, and well suited to the task it is meant for (which includes RPC-style communication).
ONC/RPC is another standard protocol for RPC supported in the Unix world and support also exists for Windows platforms. It is well documented, and bindings exist for C/C++ and Java, amongst others.
Opening a socket and sending strings is easy, but it is also slow and error prone. The use of binary encoding for numbers (which constitute a huge proportion of most parametric and return data in typical applications) is far more efficient in terms of bandwidth, processor usage and code quality.
As for ignoring tags, this is a hack concept introduced by this technology, and is something to be considered with the utmost suspicion from a software engineering viewpoint. Servers should never ignore parameters from a client, as these are (obviously) there for a reason. This type of thing causes subtle errors in distributed applications that are incredibly hard to trace, because they relate to application versioning rather than functionality -- and few organisations have configuration management skills or procedures to match their testing/debugging procedures.
I'm not recommending home brew. But I am also not advocating (in this situation) a multiply-redundant encoding with unreasonable overhead which is not meant for a high-volume environment. There are many preexisting standards which meat the requirements, but aren't buzz-word compliant.
You're right - the use of native threading (mostly) precludes the definition of stricter / more reliable scheduling rules. This was intentional in the current Java specification, to allow the use of native threads.
Frankly, I have no idea how to reconcile the two;) Unless the specified behaviour is something you can expect to be supported on all implementation platforms (very unlikely).
My bad experiences with Java threading have been mainly with VMs based on Windows and Solaris, where threads contend for resources in a situation where I can't make the locks more fine grained (the requirements are complex but very specific about the behaviour of threads in resource contention).
On Windows the software behaves just fine, whereas on Solaris one thread hogs the resources all the time. This is exactly the same behaviour as the equivalent C++ application - but with that the problem could be solved using the wider variety of synchronisation primatives (e.g. overlapping mutexes).
So, as I suggested, additional synchronisation primative may go someway to relieving the problem; but a more deterministic scheduler would be nicer... but run into the problems you have accurately described.
Please read the SOAP specification. It was born out of XML-RPC, and developed (amongst others) by the same author. Its initial and primary focus was remote method call, which is merely RPC in an object environment.
While it can be used for asynchronous notification, the specification deals mostly with the request and response case, where an identified function is invokved on a server and the invocation is provided with supplementary data (arguments), while the client waits for a responses which can contain arbitrary data (return value, possibly an object or structure) or out of band return data (and exception).
SOAP was intended to kill XML-RPC, and to add functionality over and above XML-RPC (such as callbacks / notification). It is still an RPC mechanism at its core.
to a lot of people, is a damn sight better than C++
There is a domain of usage suitable for any given language. To a lot of people, Java is far better than C++ in the domain in which they work. You even acknowledge this.
Java cannot be applied to operating systems because it does not have the syntax or functionality to control hardware with the required precision. Java recognises that by providing JNI.
Office suites and web browsers represent a huge amount of code investment - something only one company (Corel) has been willing to risk given the infancy of Java at the time. Were MS, Corel, Lotus etc to start on a level playing field right now, with all their knowledge, and expertise in the language of their choice, but no existing code base, the choice of technology (out of C++ or Java) would be a very interesting question; but my bets would be on Java to deliver a robust solution in a shorter time. The primary factors holding Java back for these applications are the performance issues in Swing, and the poor integration with the platform look and feel.
Just because you are not competent in C++ does not mean it is inferior to Java
Actually, this is CONTRARY to a basic rule of software engineering, which is that the best tool for the job is the one you know. No team can deliver a robust, quality solution based on a platform with which it is not familiar.
That said, I am an experienced C++ and Java programmer (amongst others), and work extensively with cross-platform products in both languages. Each has their place, but for every application where the requirement for stability has outweighed the requirement for speed, I have found Java the correct solution.
Even where speed has been a tantramount consideration, there has been a cost benefit in using a Java implementation (shorter development cycle and quicker time to market versus more expensive hardware).
Slashdot Mirror
56. (1) The Minister may prescribe minimum standards or prohibitions in respect of--
(a) the general management of critical databases;
(b) access to, transfer and control of critical databases;
(c) infrastructural or procedural rules and requirements for securing the integrity and authenticity of critical data;
(d) procedures and technological methods to be used in the storage or archiving of critical databases;
(e) disaster recovery plans in the event of loss of critical databases or parts thereof; and
(f) any other matter required for the adequate protection, management and control of critical databases.
Actually there is a significant amount of research into the phenomena which sees people lose or relax social and/or moral control when given anonymity.
The opportunity to vent destructive behaviour otherwise unacceptable in society is a coping mechanism employed by some people. It is often done in a (socially) harmless manner - yelling in your own back yard, hitting walls, going to gym - but occaionally people go "over the edge".
Anonymity brings the edge closer: it seems that people are just naturally more destructive when they cannot be held accountable.
At the core of the whole problem is that a society cannot exist with true anonymity. Society requires the ability to identify individuals who are acting against society.
Just FYI: The FONT tag, which is at the center of his rant, IS a standard. Unlike CSS, its going to work properly on almost all browsers. Unlike Hx tags, it doesn't impose formatting on itself or surrounding text - something even CSS isn't great at controlling.
Take a look at David Baron's CSS test results - they are mainly for 2000/2001 browsers, but that includes IE5 and 5.5 which are the most common browsers on the Internet today. It reveals a mass of buggy, unsupported, non-compilant or incompatible implementations of CSS.
Now go to About.com's web design compatibility page and get an idea of the incompatibilities in newer standards between browsers. The result is quite obvious: using CSS is NOT a route to gaining compatibility and avoiding hacks - more than likely its going to involve additional hacks and even further limit browser support.
Coding to de juro standards is useless if the standards aren't properly supported. People have more success following de facto standards, which is why so much of the web is IE-centric.
As I noted in my post, my suggestions may be totally unsuitable for the application - but then there was little information given about the nature of use that is expected. I'm glad to hear an opinion from someone experienced with the other end of the scale.
In my (limited) dealings with data warehousing systems, performance has been a non-issue. These systems have mostly held historical data for occasional retrieval. Often the (in)efficiency of the database system has been the bottleneck. We're talking 10 to 50 TPS on simple queries or blocks or data.
As opposed to the solutions offered by today's high end vendors, RAID takes on its true meaning in this sort of slower-moving-data system. Commodity hardware means less stability, but the warehouse is not a mission-critical system (it can take occasional, short outages). On the other hand it is cheap and easy to replace.
I am not an expert in this field, but Google was willing to tell me lots.
RaidWeb sells rack mountable RAID units that take IDE drives and have SCSI or fibre connectivity. A 12-bay 4U SCSI (with 12x 120Gb IDE drives) system comes in at just under $8000, giving over 1Tb fault tolerant storage. There are several other companies that have units like this.
Rackmount Solutions sells rackmount cabinets. A 44U cabinet with fans, doors, etc. will come in at around $3000.
In theory, a single cabinet could house 11Tb of data, and cost around $91000. This still doesn't consider cabling, cooling, power distribution, networking, a proper server room (air con, false floor for cables, access control), and in all likelihood one or more controlling servers.
More practically, depending on how they are going to make this data accessible, you could be looking at 9 raid units per cabinet plus 3 2U servers and a switch in the remaining space. Each server can support multiple SCSI cards and gigabyte networking. Such rackmount computers will set you back in the region of $6000 (incl. network and SCSI adapters, excl. software).
So you can call it $100,000 for 9 Tb storage ... $600,000 for 54Tb. That doesn't answer the management software question, and may not be a suitable solution. But it sure is a lot cheaper than $20 mil ;)
#define c BAD_ENGLISH
c++
You don't honestly think I type "clock" in day to day life, do you?
ARGH!!
Too many people are under the impression that implementing a clone is not an infringement of Copyright. Mistake. Copyright doesn't just cover a work, it covers derivative works too. Take the functionality and interface, and you're creating a derivative.
I haven't used either product, so I'm not going to state that they are similar. Clearly Apple thinks so, and a number of users on this and other forums think so as well. The developer's response also makes it clear they were out to achieve the same ease of use - which often comes down to interface design (functionality wise, not necessarily look and feel).
Software design, much like the plot of a book, is protected by Copyright. Interface design, much like the cover of a book, is too. Create a new plot or cover art from scratch, which is different to the original but uses conceptual elements from it, is not a violation of Copyright. It can be a fine line at times.
The article very definately uses the words "detect" (light behind) and "generate" (image in front). This implies it is not some passthrough technology (fiber, etc), but an electronic record and recreation.
If this "clock" could live up to its claims, there are three (possibly more) far more interesting applications that must be considered:
Given that researchers would be coining it from more down-to-earth inventions like these, I can't really see that the technology - as described - exists or is being developed.
Creators of remote controls could learn a lot from a simple philosophy behind the success of Windows: Point And Click.
A laser pointer (so you have feedback about where you are pointing) with 6 buttons which have common meanings to household objects could control most of the functions that remote controls are concerned with:
...and so on. You don't get to program your VCR (timer record, tuning, etc), but you get the important functionality that you want access to remotely (for the average non-couch-potato). The other drawback is that elderly or disabled people may find it more difficult to have to point (assumedly with some degree of accuracy).
With a bit of additional logic, you can add a minimal LCD display so up/down scrolls through the control options, and left/right manipulates them.
Not even vaguely - this is a clear generalisation. I have no experience with AS/400. However, in my expierience, there is often a reluctance to move to new technologies, and the justification is often to cite them as "immature" and "unproven", whether this is or it not the fact.
I would contend that Linux as an operating system - not all of the junk on top, just the basics - is a proven, stable and reliable system. It runs a significant number of high-uptime, high-volume hosts on the Internet, and has the support of three major vendors of top-end hardware (Sun, HP and IBM).
On the other hand, I firmly believe that if a system works, and does what it is needed to do, don't screw with it. This is, however, completely at odds with the sales strategies of most IT companies.
I am surprised that as an "IBM business partner" the article's author hasn't consulted IBM on how THEY are intending to push Linux to their customers.
One person's mature standard is another's legacy nightmare.
As a non-christian, perhaps I can offer some enlightenment. To begin with, I do no believe in a single all-powerful being. I see no evidence of such a being, and I feel no need to believe in a higher power. On the other hand I do not dismiss the possibility of the existance of such a being - I see no evidence of that either. In short, I am agnostic.
Were I to believe in a higher power, it would not be the christian god, and certainly not as portrayed by the various modern demoniations. My reasons are quite simple:
Much of the church's morality it derived from letters and books of man included in the bible, which do not accurately reflect gods intentions. There ideas have no place in modern society. Christians cling to the ten commandments, but ignore the rules that are laid down in the pages which follow them. Have you had your mildewed leather clothing ritually cleaned by a priest?
Too many christians use divine forgiveness as a safety net for their mistakes. Its a great way to avoid the whole psychological problem of a conscience - dump the whole problem on god's doorstep, and he's says "there there, that's ok".
It works wonderfully, until you're on the receiving end of whatever evil was done. Forgiveness doesn't undo fraud, theft, murder, or a billion other crimes. But in a christian society it does make the courts take a more lenient view, despite this being unconstitutional in most of the world.
To be fair, all of these are weaknesses of people, and the organisations that support the religion. I am avoiding the inconsistencies of the religion itself (something that I would have assumed would get on the nerves of geeks more than anything else), not to mention the number of conflicts or murders in the modern and medi-eval worlds that have been in the name of this religion.
If I tell you that BASIC is better than Perl, you will probably laugh. But BASIC has a 38 year history, is supported by the world's largest software company, and used by over 8 million developers worldwide. Perl is 15 years old and has somewhere over 1 million developers. The popularity of BASIC leads to misinformation and ridicule of Perl.
THAT, is religion.
It has to be remembered that Use Cases are customer-centric. They are intended as a semi-formal communication medium which can be understood by customers, analysts, designers and developers.
As such, a system which realises a Use Case may look nothing like the Use Case.
On the other hand, an Object Oriented application is often best designed to mimic the "real world", so your objects and methods tend to drop straight out of a use case.
The usual technique is to take your annotated UML diagrams and pick out the nouns and verbs for each Case, filter them down to a minimal set, and those are (more or less) your objects and methods.
This still involves recapturing though, but this is unavoidable. It is dangerous to think in objects at an analysis level - you tend to make invalid assumptions without even realising it. e.g. A developer is a salaries employee and a cleaner is a wage earning employee. Now, where do you put the contact developer ...?
Because you can't capture the objects along with the requirements, you must identify object candidates from the requirements, and determine a suitable design in which they will interact correctly according to the actions/verbs/messages indicated by the requirements.
Then you have to consider everything that the users won't like, the managers will add because it may be useful, and the beancounters will strip. Ew, bad image.
UML is a descriptive language for the entire software process. It crosses domains for which there are no direct mappings ... and if there were, customers would be putting in Use Cases and getting out software, with MicroRational/RationalSoft Inc. in between.
The SMTP protocol includes two 3xx response codes; one is "address not local, forward to remote@address" (client agent must handle forwarding), the other is "address not local, will forward to remote@address" (server will do the forwarding).
You are assuming the training is aimed only at programmers and for the purpose of teaching programming. This is seldom the case - most often training is used to promote a programmer's skills to include design knowledge, or management.
Where the object is to teach programming, the result is often shocking. Experienced C/C++ developers regularly come out of courses saying "Hey, I had no IDEA it worked like that".
Many developers take a "know one, know 'em all" approach to languages, without understanding that every language has its own unique way in which it is best applied. For all their syntactical similarity, Java and C++ are worlds apart in the way they should be used, for example, algorithms which are efficient in one are dogs in the other.
I have never been on a training course where I have not learned some useful piece of information. Even a presentation of the Thinking in Java course (after I had read the book and had 5 years of experience with Java) provided some insights which proved useful during project implementation.
On the other hand, I have never met someone who can be an "expert" on a language in one week. There is a lot more to language than syntax, and if you believe otherwise, you are seriously deluding yourself.
After an argument with higher calculus I dropped out of university, got a job, and later picked up my studies part-time by correspondence - the traditional mail, books and paper kind.
If you are a good learner and/or have time to dedicate to your studies (a couple of hours a day, preferably), I think this is an excellent way to go.
I completed my degree through UNISA (the University of South Africa). They offer a number of excellent courses in all faculties, including postgraduate studies; have over 110,000 students, are recognised worldwide and examination centers in many countries.
Some of the faculties are most suited to international students than others. The computer science department, for example, accepts most tutorial submissions online. I see their home page has links for online registration and payment as well.
UNISA will allow you to transfer credits from recognised institutions (up to a maximum of half the total needed for your degree).
This is a bit of a shameless plug, but if you're going to get a qualification, it is worth getting it from a known, recognised and respected institution.
Some information on requirements for foreign (non-SA) students
I think you'll find that this is the intention behind a law to force software to provide warrantees ;)
Just FYI: My dad runs his home PC on Windows 95. Some of his friends use Windows 3.1. They don't suffer continual failures, etc, that we usually attribute to these systems. When you aren't pushing the OS, and are running reliable applications on top of it, you can expect many years of good service, even from w95. Sadly, it is hardware failures and the lack of w95 driver support on new peripherals that are forcing him to consider a sidegrade to a newer version of windows.
I assume you are aware that a number of higher end (umm ... luxury ;) ) vehicles these days effectively DO have welded hoods. The maintainable parts of the engine are locked away in compartments which require special tools to access - the type you can only get hold of it you agree to a dealer contract with the manufacturer.
Despite this, there are still millions of people who drive BMWs, and Windows.
For academic instruction XML is not a bad idea at all. I believe it is a bad implementation, not a bad concept. It is conceptually ideal for many forms of communication, and has benefits in academia: it is well studied, resources are available, and it is easy to view the protocol in action and dissect every step (without resorting to deciphering binary packets).
I'm sorry I didn't present the second part of my argument clearly. The problem of ignoring parameters is more serious when you can't upgrade everything simultaneously, and especially when you upgrade the client first.
For example: a method is upgraded to take an additional parameter "skew" (it just adds that number to the return value). The client happily calls the server, not knowing that the server is running an older version of the software, which ignores the "skew" parameter, and returns the wrong result.
Careful schema control, and having the client identify its schema/API version to the server is a good way to handle this, but developers are notoriously bad at meticulous API versioning (which falls into the category of tasks I referred to as configuration management).
The best practice is to clearly separate the two versions of the API -- introduce completely new functions when you need to add parameters, don't simply use what appears to be overloading (but isn't). An alternative practice is to use inheritence to make v2 of the API a subclass of v1, with additional (possibly overloaded) functions.
Essentially, you need to treat the distributed environment no differently from objects on a local machine. If you add parameters to a method, you must provide a new, separate, overloaded method. Changing the existing method would break existing code which uses it - so you don't do it. If it makes sense to do so, the old implementation can be changed to call the new method with some default parameters - but this is not always the case.
As a rule, ignoring data is a bad thing. It its not used, it probably shouldn't be there ... and if it's there, it should probably be used ;)
AAMOI, the Visa 3D-Secure specifications permit certain communication end-points to ignore certain fields for forwards compatibility, but within a strict framework: some servers and/or messages cannot ignore fields, and any field of any message can be marked such that the recipient MUST understand the field, or force the transaction to fail.
But, it must also be understood that the Visa framework does not operate using SOAP (or a system where the target function is indicated within the request); updating legacy systems to talk to new URLs (possibly multiple URLs, to support multiple versions) because an API has changed is not an option, and the framework has been designed to operate within the constraints of the current web services that offer e-commerce.
Java has no assembler level instructions to do port IO. It also doesn't provide you with direct memory access - which goes beyond alloc/free as you need to control the descriptor tables which define memory protection. Then you have the problem of handling interrupts (not only hooking them, but masking and unmasking, which on most architectures as CPU instructions), etc.
Without JNI, you can't hope to achieve any of this. C/C++ allows you to "drop down" to asm at any point, in such a way that the asm is compiled into the final object code. Java has no such functionality.
It *may* be theoretically possible to create a Java kernel on a system built specifically for that purpose - by allowing hardware control (IO, memory protection, interrupts) via memory mapping; but I still think you'll find you need to run a microcode interpretter on the CPU to handle garbage collection (amongst others), and a class to provide direct memory access to the mapped regions -- neither of which could be expressed in "pure" Java.
You know the problem with the world? There are too many developers out there who will read your first paragraph and say "That is such a cool idea - I'm going to do it right now!" ...
There are several existing standards for the interchange of information between disparate systems, and that includes languages. And a number of those are complete remote procedure call systems.
ASN.1 has been around since 1984 (or somewhere close), and is a terse binary protocol build for this sort of communication. It is used extensively in the telecoms industry and is supported in almost every language. It is standard, well known, and well suited to the task it is meant for (which includes RPC-style communication).
ONC/RPC is another standard protocol for RPC supported in the Unix world and support also exists for Windows platforms. It is well documented, and bindings exist for C/C++ and Java, amongst others.
Opening a socket and sending strings is easy, but it is also slow and error prone. The use of binary encoding for numbers (which constitute a huge proportion of most parametric and return data in typical applications) is far more efficient in terms of bandwidth, processor usage and code quality.
As for ignoring tags, this is a hack concept introduced by this technology, and is something to be considered with the utmost suspicion from a software engineering viewpoint. Servers should never ignore parameters from a client, as these are (obviously) there for a reason. This type of thing causes subtle errors in distributed applications that are incredibly hard to trace, because they relate to application versioning rather than functionality -- and few organisations have configuration management skills or procedures to match their testing/debugging procedures.
I'm not recommending home brew. But I am also not advocating (in this situation) a multiply-redundant encoding with unreasonable overhead which is not meant for a high-volume environment. There are many preexisting standards which meat the requirements, but aren't buzz-word compliant.
You're right - the use of native threading (mostly) precludes the definition of stricter / more reliable scheduling rules. This was intentional in the current Java specification, to allow the use of native threads.
Frankly, I have no idea how to reconcile the two ;) Unless the specified behaviour is something you can expect to be supported on all implementation platforms (very unlikely).
My bad experiences with Java threading have been mainly with VMs based on Windows and Solaris, where threads contend for resources in a situation where I can't make the locks more fine grained (the requirements are complex but very specific about the behaviour of threads in resource contention).
On Windows the software behaves just fine, whereas on Solaris one thread hogs the resources all the time. This is exactly the same behaviour as the equivalent C++ application - but with that the problem could be solved using the wider variety of synchronisation primatives (e.g. overlapping mutexes).
So, as I suggested, additional synchronisation primative may go someway to relieving the problem; but a more deterministic scheduler would be nicer ... but run into the problems you have accurately described.
Please read the SOAP specification. It was born out of XML-RPC, and developed (amongst others) by the same author. Its initial and primary focus was remote method call, which is merely RPC in an object environment.
While it can be used for asynchronous notification, the specification deals mostly with the request and response case, where an identified function is invokved on a server and the invocation is provided with supplementary data (arguments), while the client waits for a responses which can contain arbitrary data (return value, possibly an object or structure) or out of band return data (and exception).
SOAP was intended to kill XML-RPC, and to add functionality over and above XML-RPC (such as callbacks / notification). It is still an RPC mechanism at its core.
RTFS (statement):
There is a domain of usage suitable for any given language. To a lot of people, Java is far better than C++ in the domain in which they work. You even acknowledge this.
Java cannot be applied to operating systems because it does not have the syntax or functionality to control hardware with the required precision. Java recognises that by providing JNI.
Office suites and web browsers represent a huge amount of code investment - something only one company (Corel) has been willing to risk given the infancy of Java at the time. Were MS, Corel, Lotus etc to start on a level playing field right now, with all their knowledge, and expertise in the language of their choice, but no existing code base, the choice of technology (out of C++ or Java) would be a very interesting question; but my bets would be on Java to deliver a robust solution in a shorter time. The primary factors holding Java back for these applications are the performance issues in Swing, and the poor integration with the platform look and feel.
Actually, this is CONTRARY to a basic rule of software engineering, which is that the best tool for the job is the one you know. No team can deliver a robust, quality solution based on a platform with which it is not familiar.
That said, I am an experienced C++ and Java programmer (amongst others), and work extensively with cross-platform products in both languages. Each has their place, but for every application where the requirement for stability has outweighed the requirement for speed, I have found Java the correct solution.
Even where speed has been a tantramount consideration, there has been a cost benefit in using a Java implementation (shorter development cycle and quicker time to market versus more expensive hardware).