Hi. I'm afraid I still fail to understand how this shortcoming is intrinsic to TCP w.r.t server connections.
When a client makes outbound connections, each connection must be from a unique port. A client cannot share a port used by a server, and port is a 16 bit value, so there are (65536 - server ports - 1 [0 is not addressable]) client connections permitted from any given machine.
Now when it comes to the server, the situation is different. A server connection is identified by a single port on the server, irrespective of the client. The server distinguishes the client connection based on the client's IP and source port. That gives an intrinsic limitation of about 64k connections per client IP, and about 4G IPs.
I see no reason why this 'bookkeeping' (when applied to server connections) has to be done with a 16 bit number. That sounds like an arbitrary operating system limitation. It would imply that an incoming packet is examined for IP and source port, that looked up in a table with max 64k entries, and the result taken to be the connection id. This makes no sense -- the kernel would look up the ip:port combination and get a unique stream identifier, which is an int (32 bit).
Could you please explain clearly (in theory, or in terms of OS implementation) why this isn't the case? Thanks.
Hi. No bug in the OS or the kernel, but in assumptions;) Our server is tailored for performance under load, not for massive amounts of idle connections. In such a scenario the time taken by select() has a serious impact on the overall performance.
In instant message by contrast, I will agree with you that the lighter processing load will be less affected by scanning (mostly idle) descriptors.
You indicate that your scalability problem kicks in at around 64000 simultaneous clients. Having developed high-performance scalable servers I would recommend taking a look at The C10k Problem, which is rather sobering: handling 10000 simultaneous connections is already a bitch.
Basically if you are using select() or poll() and have 10000 connections, you can expect 30% of your timeslice (on a fast machine) to be taken scanning the connection list for available data. Your performance also goes down the drain after about 250 connections (empirical observation; our server handles async requests which are offloaded to a hardware device for processing, so most server overhead is packet handling).
To get more connections than that you need to look at OS-specific methods: IOCompletion ports on NT,/dev/poll on Linux & Solaris, and kqueue on FreeBSD. These scale must more linearly out to 10000 connections (depending of course on if your server can handle the total load), but still don't give you the ability to scale endlessly.
Finally, I know of no intrinsic reason (although OS implementations may have arbitrary limits) why a server should be restricted to 64k connections. A TCP/IP connection is defined by two endpoints, each being an IP address/port cobination. Your server's ip/port is always one of those endpoints, and the client are unique. Client connections on the other hand are limited by the number of available port on the computer, i.e. 64k.
For fault tolerance, your best bet is to look at the architecture of Enterprise Java servers. Effectively you have a load balancer up front which redirects packets to one of several application servers; any persistent information must be saved off to a database server, and if necessary two or more database servers must be configured to synchronise with each other on a continual basis.
I am not aware of any software that can magically do this for an arbitrary application, although you may find network shared memory libraries which can more or less accomplish this. But if you are concerned about performance, you are unlikely to find COTS software to do the job (since the current business model is to throw more computing power at it).
Religious? No. Obsessive? Often. And with good reason; I'll let you in on a few.
Your average Java programmer is not a happy-go-lucky hacker. He works for a living, and wants a language that supports his development.
With Java he gets:
An extensive, well documented class library. This more than anything, more than syntax, more than platform neutrality, more than speed, more than any underlying technological benefit of any other language, more than you want a blowjob tonight, is what a serious wage coder wants from a language.
Garbage collection, for added stability and not being anal retentive about freeing memory. Also easier to use than smart pointers.
A pure-OO framework that allows designers to design stuff so that coders can't screw blissfully with each others minds, because there are no "back-doors" and the protection is run-time.
No operator overloading or line noise syntax, so when you come to maintain the code done by the vac. student (guru hacker from outer space) you have a clue what it means.
I like Java for all these reasons. I also like C++, for its power and the extra 5% performance I can squeeze out of it if I need to, and because I'm anal enough to do it right. But I've worked with more than a dozen people who weren't, so it became my problem to fix their mistakes.
One final thing. Using an Apache-style architecture, a Java server can happily achieve 90% of C++ performance on most client-server applications. And I've worked on two projects that prove it.
You seem to have grasped one of the central concepts of OO, and a fraction of its usefulness. You have yet to come to terms with its real worth, or the Greater Picture.
To a limited extent OO is the "reverse" of passing around a data structure. It is convenient, and to most people more logical. But most importantly it offers something that non-OO languages cannot provide: compile time type safety and encapsulation.
The and is really important, because a non-OO language can offer either, but not both. This means than a function can never be entirely sure that its data is in a consistent or expected state, which an object can.
Aside: to provide compile-time safety to must declare the entire data structure, and not do any type-casting. But to provide for encapsulation you must hide the data structure, so that a developer cannot at compile time reference any member of the structure by name (i.e. can't screw with the data without making assumptions about offsets that equate to hacking, and will not remain true if the data structure changes). Doing both is not possible without additional code in the function to calculate and check some sort of checksum of the data structure; and that does not provide for compile-time error checking.
This may not seem important, but it greatly reduces bugs. You can code and debug a library of objects, happy in the knowledge that no other part of the program can screw with the objects' minds. Never underestimate the value of compile-time error checking; a well-designed program may most of its bugs in this fashion!
And now we move on to more interesting stuff, like inheritence and polymorphism. (And no, "templates" (parametised classes, for the better educated) are not OO).
OO is not about "making programming easier". It is about creating a more logical structure to allow the application of engineering principles to software design and implementation. This means improving robustness and maintainability.
OO achieves this by reusing code in a more effecient fashion than procedural languages; as a direct consequence of inheritence.
In any situation being modelled by software there tend to be a number of data-bearing entities (physical objects, processes, representations) with similar properties and having similar functions. OO allows the similar properties and functions to be matched, factered out and reused across all the entities.
Non-OO languages can approximate some of this functionality by using embedded or chained data structures, but they lack a significant capability: to automatically adjust the function according to the entity.
This difference is best illustrated by considering an office with a manager, secretary, clerk and some production workers. The manager walks into the office and says "all of you, do your job!". Simple, and OO.
In the non-OO case the manager walks into the office and says "all of you, if you are a secretary answer the phone and do the filing, if you are a clerk total the books, if you are a production worker on the Toy line then build toys, and if you are a production worker on the Pen line then make pens."
OO simplifies the procedural logic which controls a situation, because each object knows how to behave in an appropriate way in reaction to a more generic instruction.
If you find no benefit in OO other than "it makes coding easier" then you are missing the point, and I would suggest getting a good book on the topic and reading it thoroughly.
I'm sorry, but this is a classic example of bad OO, except in specific circumstances. A simple calculation is expanded into 6 method calls (3 x setCoefficient, 1 x calculate, 2 x getRoot), and even if compound methods are provided the side effects grossly impede calculation performance.
An object can represent anything that has a state which changes over time, in response to input or other events in the software. If what you are modelling does not hold with the above definition, it shouldn't be an object.
Discrete calculations are especially suited to NOT being objects. They have no requirement for persistent information outside the function, and thus no need to be in an object. The primary reason for putting them in an object is grouping, which is a Really Bad Idea for common library routines because you can't export C++ objects from libraries (unless you assume that the library user has the same compiler and linker as you do...).
Fortunately C++ (unlike some other OO languages) has a solution to this problem: namespaces. Any function which is self-contained (has no need for non-local data) can be placed in a namespace, logically grouped with similar functions, and if the header is carefully constructed can still be used in libraries using C name "mangling".
The only situation in which I can imagine the object you propose being useful is as a data object behind a GUI which allows you to enter quadratics and fills in the other fields. And even in this case I contend that the correct model would be a QuadraticModel object (like the one you describe) which calls calculateQuadraticRoots() in a namespace or other library.
In my (limited) experience with crackers, the ones that are actually breaking protocols (rather than running scripts) tend to be older and with good resources... typically high school or undergrad.
In either of these positions (but esp. undergrad in elec.eng or similar) such folk are likely to have access (or be able to access without too much trouble) school of university facilities. Certainly most of the universities here have some fairly powerful transmitters available.
Anyone listening in on the command streams and watching intently enough will be able to piece together the protocol in time... by experimenting they risk damaging things but can speed up the process.
I considered this, and decided to describe a simpler system;) But there is no reason that content can't be classified with better granularity than "adult/non-adult" ; then each country can insist that ISPs implement filters according to its laws.
Its not as difficult as you think. You get political agreement between consenting countries to support this effort. In legalese it would be a treaty to rate content and penalties for governments and individuals who flaunt the rating system, whether by technical means or blatent lying.
Since the countries would oblige all ISPs to behave in a particular manner, that group of treaty-bound nations can ensure that all connections to anywhere OUTSIDE the treaty group are treated as adult-only (even a special tag: adult-only, non treaty ; so that nations wanting adult censorship [not that I hold with this] can do so).
The all traffic from outside the treaty nations is considered unsafe for children. Within those nations any flaunting of the rating system can be followed up through normal legal channels.
Its not really a matter of legislating the net, but of putting a technical system in place that can support various legislation (as I suggested in another post: make content classification more granular than simply adult/child) and getting buy-in from countries to agree to enforce that if ratings are used they are accurate.
Why not? Restrict non-adult access to certain protocols only; ones for which the protocol definition has been updated to include a content descriptor. UseNet would obviously be out, but web boards could be a suitable replacement.
Technically restricting P2P is more difficult though... but it comes down to having reasonable guards in place, and law to deal with offenders. e.g. A P2P service with "message" and "file" modes may be allowed to non-adults in message mode. Any software capable of circumventing the restrictions (P2P software which builds a file from multiple messages) must have adult access only ; if the distribution site doesn't ensure this, then the distributor is in transgression of the law.
As I said - this is not a perfect solution. But we don't have any systems in place for more traditional media that are perfect.
Every time censorship of the Internet is brought up, the geek community shoots it down in flames as being impossible or impractical. But what if technology was to meet legislation half-way?
Here's the proposal (although to some extent it only works with global-treaty buy-in):
Every ISP is legally obliged to distinguish between Adult and Non-adult accounts. They are also obliged to run a transparent proxy service through which all connections must pass.
An extension is made to HTTP (and other relevant protocols) which includes an Adult/Non-adult content flag. This allows the proxy to block connections to inappropriate sites.
The further legal obligation is on all site owners and maintainers (and hopefully not the hosts!) to ensure that their sites comply with the rating they claim.
There is also a legal obligation on all adults NOT to make their account (password) accessible to minors; and only to allow minors access through their account if they are a legal guardian (or acting on behalf of one) and the minor is under constant supervision.
This is very much like existing censorship systems, but with three major differences: it is more transparent, there is legal recourse if the site fails to live up to its claimed rating, and there is an onus on adults to protect children (while not denying parents the right to allow their children access to material as they see fit).
Yes, there are ways around this. There are always going to be some sites that evade the law, just like there are porn shop owners that ignore the age of their patrons. There will be kids who "steal" adult accounts, just like they sneak into R movies.
But it is a great improvement on any system that is currently in place, and could be a suitable middle ground for all parties.
So this implant is intended for medical use, and subsequently identification? What does it offer that a bracelet with a MedAlert number or (to get high-tech) a smart card (on the bracelet) doesn't (in terms of medical detail)?
How does this assist in identification? The object of accurate identification is NOT to track ordinary people (except in aggregate), but to track specific people. Those who currently go to great lengths to avoid being identified, bypassing existing security and forging their credentials.
And, as usual, the Great Propaganda Machine assumes that because Joe Public can't remove an implant or modify it somehow, neither can a well funded terrorist.
Most disturbing, however, is the list of exceptions that will arise. Anyone who any government determines should be incognito will be able to get "fake" implants or avoid implants altogether. You don't want even a short range transmitter giving away the location of your crack troops, do you?
Just a casual FYI: My Hi-Fi has 4 buttons to control the CD tray and selection, another 4 to control the input source (casette, cd, tuner, aux), another 6 for various graphic equaliser options, 12 buttons to control the tapes, and one volume knob.
And just to complicate the issue, you won't get any sound out of the TV alone because its rigged to play through the aux ; similarly the TV isn't tuned to any channels, but accepts input on aux from the VCR.
The VCR, in addition to its 8 buttons, is programmable from an OSD.
This is not a typical household setup, not does it perform "a single function". What is important is that there are a limited set of functions most "users" use, and those are highlighted on the remote(s) in luminous blue (gotta love Tiwanese stuff;p ).
The single most important part of designing an interface (for a computer) is to hide complexity without "hiding" it. Reduce the number of options at easy choice point to 7 +- 2. Don't do stupid MS stuff like hiding infrequently used options - users get confused ; it also means the user has a heck of a job investigating the full capabilities of the application.
An extension to this: your menu bar should have 5 to 9 menus, each with 5 to 9 items (possibly sub-menus), and each sub menu should have 5 to 9 items with NO submenus. A submenu should never invoke a dialog or be a "checkbox menu". In this manner you reduce the overall complexity to something a user can reasonably nagivate.
...and despite all this time, effort and money, most people still find computers complex to use.
My SO can pick up a remote control, figure it our without the manual, and operate the TV, VCR, and Hi-Fi. So can my parents. They are happy to set the message on their answering machine, program numbers into their phones, do combo-cooking with the microwave and generally use your average household technology without instruction... but not a computer.
First you have to know about the idea of clicking with the mouse. The whole left-click / right-click thing which we take for granted and do 20000 times a day is NOT easy to catch onto for a new user. Once they have the idea, they still do know what to do.
"Start button? But its already started, why do I want to start it again?". How about the little icons on the taskbar? Any idea what they mean if you haven't been told? There's a deskpad with a notebook and pencil on it [looks like a writing application, but its the desktop]. Then a big blue "e" [here is South Africa we have a TV channel called "e" with a very similar logo]. Then a clock inside a square [that would be outlook].
When there IS a window open, there's three funny looking icons at the top right. Ask a new user if they can guess what they mean.
With the exception of international standard symbols (like the power symbol), most people can't guess the meaning of icons. Your average Word user goes on a 3 day course to learn the basics of clicking on the correct toolbar icon, when they could select a perfectly meaningful English word from the menu system.
The whole idea that GUIs are easy to use is a myth, as is the idea that icons are somehow more meaningful to users. These ideas have been forced down our throats by marketing droids and the odd technical writer who things (s)he knows his/her stuff.
I think what many people (including the author of the original article) fail to realise is that the hard drive icon is NOT part of the desktop, or even related to the desktop. It is the computer visualisation for getting up, walking away from your desktop and opening your file cabinet.
The two are very different, and both required. You cannot organise yourself effeciently with even a thousand desks - you need a filing cabinet. Conversely you can't work from a filing cabinet at all times - you need to take out a file, strew some pages around your desktop, and get on with stuff.
Sorry, but I have to disagree here. As much as I and may others dislike it, what you do in public is not protected by privacy laws, or even concepts.
Where you work and what you do (for a living) is, in almost all circumstances, public knowledge. If for no less reason than an arbitrary person on the street can observe that you usually drive a red Ford and always appear at a particular office block in the morning.
What the problem is here is that "they" are starting to invade our homes. "They" can uniquely identify us in private, and build a profile not of a group, but of an individual. THAT is invasion of privacy. If I watch TV screens in the window at a mall, I can't claim privacy. When I watch my TV at home, I expect my activities not to be tracked unless I have specifically been informed AND consented.
Basically, if you're on public property, your actions are public. On private property, they are private. On corporate property they are representing the company. But electronic media complicates the issue dramatically.
I can access private property (my home e-mail) from the physical location of corporate property. How is the line on privacy drawn then? Arguably (unless I have permission) I am committing fraud for using corporate resources for private gain (doing personal stuff on company time). Even if I have permission could the content of the private mail, if it were accidently disclosed, negatively affect the company? Being their physical property don't they have a right to "invade" my privacy (as in I can expect my actions and communications to be monitored).
You may agree or, more likely, disagree. But this is a gray area. The TV issue is related: public property (broadcast signals) being accessed from private property (my television in my house). Where's the line?
As much as this freaks me and others out, consider that you don't have much better luck with other media (shock, horror!). If you want to watch porno on TV this new system is going to let marketing know that. If you go down to your local bookstore and buy a Playboy, the clerk is going to know (and probably some of the other customers too). If you subscribe then their marketing division knows directly (your name, address, credit card...), and the postman is sure to know as well.
The issue is no so much that we are being profiled, but that electronics offers better anonomity than real life, and we should benefit from that. As long as there is no way to identify the connection between a profile and an individual, few people should have problems with this.
There is a grey area of sufficient mass to sink the Titanic in there.
I don't believe in the existance of God. On the other hand I don't believe that God does not exist. Which in no way says that I believe God exists. I am agnostic in so far as knowing that it is impossible to prove (scientifically) that God exists or not.
The link you have supplied is the regular thological crap. Agnosticism is NOT "I don't know if there is/isn't/are/aren't God(s)", it is "I know that it is not possible to prove the existance or non-existance of God(s)". Atheism is NOT "I don't believe in God", it is "I believe there IS NO GOD". These are vastly different concepts, although often confused by virtue of being "opposite".
The typical position of an agnostic is therefore NOT to believe in a God (or Gods), but on the other hand not to believe that there are no Gods. In other words: They may or may not exist; all I know is I cannot use science to prove this one way or the other; therefore its not going to bother me.
"Agnostic" is not a word derived purely from the roots "a" and "gnostic". It has a distinct theological meaning (as do many other words, such as gnostic, which refers to a specific system of religious beliefs; agnostic certainly doesn't imply disbelief in or the anthesis of gnosticism). The linked article has about as much actual logic as saying that an aphid is not a phid (wtmb).
Remember, the opposition to a view is not necessarily the opposite.
Typically the various languages separate programs and utilities, and therefore function. But a logical grouping takes off of these into account.
Look no further than Freshmeat. Projects are classified and categorised. At some point you get to the source code for a particular project (as a tarball), at which point you are considering a single project.
Follow the same hierarchy for a project which has subprojects:
Complete project repository
Main application section
Main application make files
docs
source
java
c++
Utility application one section
source
perl
Utility application two section
and so on...
Your source tree needs to have no resemblance to the final product. What is important is logical separation and navigation of source. That is why you should keep the applications separate at the top. Then keep the languages separate: even when it comes to JNI the languages don't work together, but cooperate across an interface. Even your code for a single language should be broken into directories according to its logical units (any cohesive library or application with a defined interface).
Your make process can ensure that all the sources are properly colated (either implicitly or explicitly by copying or using symlinks) and build into whatever form you want.
This issue of culture is (IMHO) and important factor working AGAINST GPL in the open source arena.
I know several companies (I work for one) that either explicitly or implicitly will not use GPL or LGPL software in their development (think libraries here, not tools). Not using GPL is obvious, but LGPL is more subtle: you don't have the option to integrate the functionality directly into your application, even if you want to.
Many licenses also force you to distribute part of your application in source form (the open sourced libraries, not your own code) or to prominently mention the use of the library, which tramples on poor little corporate egos.
While I believe in giving credit where it is due (especially when you are leveraging effort done by others are no charge to you), most companies can't take the "bad press" or general perceived humiliation of admitting to using free code.
So some think this is good, because they aren't scabbing off your efforts. True. And you're entitled to that opinion.
But it is also bad. OpenSource is about getting more eyes seeing the code, and more hands working on it. Companies that I have had experience with have no qualms committing changes back to open source, as long as they can avoid the marketting problems it may create. So if your library is 90% good for a particular use, corporate time and money may just go to filling in their 10%, which they give back.
Even if its only one in a hundred companies, its worth it. And judging by the project out there working on this basis... its not that rare.
This is precisely my choice. And an important one.
I can make a library, or implement (say) a protocol I have designed. I know full well that many commercial enterprises will not use even LGPL in their applications (they will want to integrate the protocol fully), and are unlikely to support some arbitrary unknown protocol from Joe Q Public.
So instead I put the code under BSD license, so any individual or organisation can choose to use the code if they want.
Yes, I am at the mercy of MS & partners doing the embrace and extend thing, but MS has shown itself (in cases) to be incapable of that tactic if the market is already sufficiently standardized (they can't change HTTP because of Apache, and the haven't managed to corrupt XML yet).
Computer programs cannot be though of without considering "similar" works like books. A program represents an investment of time, effort and (usually) money. The final product is of interest or value to a user. This makes a program commercially viable as a trade product.
Given that programs are necessary, to force all of them to be free and/or open source would infringe on the rights of a (large) number of individuals to earn a living. Basically: no commercial viability, not a career option, no programs. Bummer.
Contrary to (unpopular) opinion, source code is not like a book. Binray code is like a book: its a finished, usable product. Should authors be forced to disclose their notes, the design of their plot, their character sketches? No. How about their "formula" for writing a captivating novel?
It is ultimately up to the programmer to decide how (s)he wants to see his/her code used. Fortunately for those of us who make a living from this soft of thing, RMS can't force us to give away everything we do for free;)
Off topic
To supplement this line: a democracy is not about following the wishes of the majority, but about compromising in favour of a majority while protecting the rights of all minorities.
This is the thin dividing line between democracy and (political) communism.
Please check if you are using any software to which I have contributed (my time and effort, at no charge). If you are doing so, I would appreciate you coming over to do some of my gardening some time.
You see, I'm not so hot on the getting down and dirty side of life, but I'm a decent hand at coding. Either of which represents an amount of time and effort.
So if I choose to code up something (using my time and effort) and give it away at no charge, I won't appreciate being told under what rights I have to give it away.
In the same way as you doing your gardening (using your time and effort) should in no way imply that you have a requirement to do my gardening, just because you did your's for free.
What I'm trying to say is: I have rights over my creations. I have the right to make it closed source and sell it. I have the right to destroy it and never let anyone know about it. I have the right to make it freely available to anyone, for any purpose. And I have the right to put it under the GPL.
And unless I give someone the right, they have no right to tell me what to do with my property. Whether you consider IP property or not is actually irrelevent - my creation is the product of my time and effort.
So if you don't like my right (when applied to my "property") to restrict your rights... then kindly remember that you don't have the right to restrict my rights when your capabilities are concerned.
Hopefully we will live in a world where we have far more freedom than exists in the States; where the president isn't awarded god-like power (at least in terms of persuasion), and where the rights of natural humans EXCEED those of juristic persons (companies).
OTOH... the States is still vastly better than most places on earth...
Slashdot Mirror
Hi. I'm afraid I still fail to understand how this shortcoming is intrinsic to TCP w.r.t server connections.
When a client makes outbound connections, each connection must be from a unique port. A client cannot share a port used by a server, and port is a 16 bit value, so there are (65536 - server ports - 1 [0 is not addressable]) client connections permitted from any given machine.
Now when it comes to the server, the situation is different. A server connection is identified by a single port on the server, irrespective of the client. The server distinguishes the client connection based on the client's IP and source port. That gives an intrinsic limitation of about 64k connections per client IP, and about 4G IPs.
I see no reason why this 'bookkeeping' (when applied to server connections) has to be done with a 16 bit number. That sounds like an arbitrary operating system limitation. It would imply that an incoming packet is examined for IP and source port, that looked up in a table with max 64k entries, and the result taken to be the connection id. This makes no sense -- the kernel would look up the ip:port combination and get a unique stream identifier, which is an int (32 bit).
Could you please explain clearly (in theory, or in terms of OS implementation) why this isn't the case? Thanks.
Hi. No bug in the OS or the kernel, but in assumptions ;) Our server is tailored for performance under load, not for massive amounts of idle connections. In such a scenario the time taken by select() has a serious impact on the overall performance.
In instant message by contrast, I will agree with you that the lighter processing load will be less affected by scanning (mostly idle) descriptors.
You indicate that your scalability problem kicks in at around 64000 simultaneous clients. Having developed high-performance scalable servers I would recommend taking a look at The C10k Problem, which is rather sobering: handling 10000 simultaneous connections is already a bitch.
Basically if you are using select() or poll() and have 10000 connections, you can expect 30% of your timeslice (on a fast machine) to be taken scanning the connection list for available data. Your performance also goes down the drain after about 250 connections (empirical observation; our server handles async requests which are offloaded to a hardware device for processing, so most server overhead is packet handling).
To get more connections than that you need to look at OS-specific methods: IOCompletion ports on NT, /dev/poll on Linux & Solaris, and kqueue on FreeBSD. These scale must more linearly out to 10000 connections (depending of course on if your server can handle the total load), but still don't give you the ability to scale endlessly.
Finally, I know of no intrinsic reason (although OS implementations may have arbitrary limits) why a server should be restricted to 64k connections. A TCP/IP connection is defined by two endpoints, each being an IP address/port cobination. Your server's ip/port is always one of those endpoints, and the client are unique. Client connections on the other hand are limited by the number of available port on the computer, i.e. 64k.
For fault tolerance, your best bet is to look at the architecture of Enterprise Java servers. Effectively you have a load balancer up front which redirects packets to one of several application servers; any persistent information must be saved off to a database server, and if necessary two or more database servers must be configured to synchronise with each other on a continual basis.
I am not aware of any software that can magically do this for an arbitrary application, although you may find network shared memory libraries which can more or less accomplish this. But if you are concerned about performance, you are unlikely to find COTS software to do the job (since the current business model is to throw more computing power at it).
Religious? No. Obsessive? Often. And with good reason; I'll let you in on a few.
Your average Java programmer is not a happy-go-lucky hacker. He works for a living, and wants a language that supports his development.
With Java he gets:
I like Java for all these reasons. I also like C++, for its power and the extra 5% performance I can squeeze out of it if I need to, and because I'm anal enough to do it right. But I've worked with more than a dozen people who weren't, so it became my problem to fix their mistakes.
One final thing. Using an Apache-style architecture, a Java server can happily achieve 90% of C++ performance on most client-server applications. And I've worked on two projects that prove it.
One day, grasshopper, you too shall understand.
You seem to have grasped one of the central concepts of OO, and a fraction of its usefulness. You have yet to come to terms with its real worth, or the Greater Picture.
To a limited extent OO is the "reverse" of passing around a data structure. It is convenient, and to most people more logical. But most importantly it offers something that non-OO languages cannot provide: compile time type safety and encapsulation.
The and is really important, because a non-OO language can offer either, but not both. This means than a function can never be entirely sure that its data is in a consistent or expected state, which an object can.
Aside: to provide compile-time safety to must declare the entire data structure, and not do any type-casting. But to provide for encapsulation you must hide the data structure, so that a developer cannot at compile time reference any member of the structure by name (i.e. can't screw with the data without making assumptions about offsets that equate to hacking, and will not remain true if the data structure changes). Doing both is not possible without additional code in the function to calculate and check some sort of checksum of the data structure; and that does not provide for compile-time error checking.
This may not seem important, but it greatly reduces bugs. You can code and debug a library of objects, happy in the knowledge that no other part of the program can screw with the objects' minds. Never underestimate the value of compile-time error checking; a well-designed program may most of its bugs in this fashion!
And now we move on to more interesting stuff, like inheritence and polymorphism. (And no, "templates" (parametised classes, for the better educated) are not OO).
OO is not about "making programming easier". It is about creating a more logical structure to allow the application of engineering principles to software design and implementation. This means improving robustness and maintainability.
OO achieves this by reusing code in a more effecient fashion than procedural languages; as a direct consequence of inheritence.
In any situation being modelled by software there tend to be a number of data-bearing entities (physical objects, processes, representations) with similar properties and having similar functions. OO allows the similar properties and functions to be matched, factered out and reused across all the entities.
Non-OO languages can approximate some of this functionality by using embedded or chained data structures, but they lack a significant capability: to automatically adjust the function according to the entity.
This difference is best illustrated by considering an office with a manager, secretary, clerk and some production workers. The manager walks into the office and says "all of you, do your job!". Simple, and OO.
In the non-OO case the manager walks into the office and says "all of you, if you are a secretary answer the phone and do the filing, if you are a clerk total the books, if you are a production worker on the Toy line then build toys, and if you are a production worker on the Pen line then make pens."
OO simplifies the procedural logic which controls a situation, because each object knows how to behave in an appropriate way in reaction to a more generic instruction.
If you find no benefit in OO other than "it makes coding easier" then you are missing the point, and I would suggest getting a good book on the topic and reading it thoroughly.
I'm sorry, but this is a classic example of bad OO, except in specific circumstances. A simple calculation is expanded into 6 method calls (3 x setCoefficient, 1 x calculate, 2 x getRoot), and even if compound methods are provided the side effects grossly impede calculation performance.
An object can represent anything that has a state which changes over time, in response to input or other events in the software. If what you are modelling does not hold with the above definition, it shouldn't be an object.
Discrete calculations are especially suited to NOT being objects. They have no requirement for persistent information outside the function, and thus no need to be in an object. The primary reason for putting them in an object is grouping, which is a Really Bad Idea for common library routines because you can't export C++ objects from libraries (unless you assume that the library user has the same compiler and linker as you do...).
Fortunately C++ (unlike some other OO languages) has a solution to this problem: namespaces. Any function which is self-contained (has no need for non-local data) can be placed in a namespace, logically grouped with similar functions, and if the header is carefully constructed can still be used in libraries using C name "mangling".
The only situation in which I can imagine the object you propose being useful is as a data object behind a GUI which allows you to enter quadratics and fills in the other fields. And even in this case I contend that the correct model would be a QuadraticModel object (like the one you describe) which calls calculateQuadraticRoots() in a namespace or other library.
In my (limited) experience with crackers, the ones that are actually breaking protocols (rather than running scripts) tend to be older and with good resources ... typically high school or undergrad.
In either of these positions (but esp. undergrad in elec.eng or similar) such folk are likely to have access (or be able to access without too much trouble) school of university facilities. Certainly most of the universities here have some fairly powerful transmitters available.
Anyone listening in on the command streams and watching intently enough will be able to piece together the protocol in time ... by experimenting they risk damaging things but can speed up the process.
I considered this, and decided to describe a simpler system ;) But there is no reason that content can't be classified with better granularity than "adult/non-adult" ; then each country can insist that ISPs implement filters according to its laws.
Its not as difficult as you think. You get political agreement between consenting countries to support this effort. In legalese it would be a treaty to rate content and penalties for governments and individuals who flaunt the rating system, whether by technical means or blatent lying.
Since the countries would oblige all ISPs to behave in a particular manner, that group of treaty-bound nations can ensure that all connections to anywhere OUTSIDE the treaty group are treated as adult-only (even a special tag: adult-only, non treaty ; so that nations wanting adult censorship [not that I hold with this] can do so).
The all traffic from outside the treaty nations is considered unsafe for children. Within those nations any flaunting of the rating system can be followed up through normal legal channels.
Its not really a matter of legislating the net, but of putting a technical system in place that can support various legislation (as I suggested in another post: make content classification more granular than simply adult/child) and getting buy-in from countries to agree to enforce that if ratings are used they are accurate.
Why not? Restrict non-adult access to certain protocols only; ones for which the protocol definition has been updated to include a content descriptor. UseNet would obviously be out, but web boards could be a suitable replacement.
Technically restricting P2P is more difficult though ... but it comes down to having reasonable guards in place, and law to deal with offenders. e.g. A P2P service with "message" and "file" modes may be allowed to non-adults in message mode. Any software capable of circumventing the restrictions (P2P software which builds a file from multiple messages) must have adult access only ; if the distribution site doesn't ensure this, then the distributor is in transgression of the law.
As I said - this is not a perfect solution. But we don't have any systems in place for more traditional media that are perfect.
Every time censorship of the Internet is brought up, the geek community shoots it down in flames as being impossible or impractical. But what if technology was to meet legislation half-way?
Here's the proposal (although to some extent it only works with global-treaty buy-in):
Every ISP is legally obliged to distinguish between Adult and Non-adult accounts. They are also obliged to run a transparent proxy service through which all connections must pass.
An extension is made to HTTP (and other relevant protocols) which includes an Adult/Non-adult content flag. This allows the proxy to block connections to inappropriate sites.
The further legal obligation is on all site owners and maintainers (and hopefully not the hosts!) to ensure that their sites comply with the rating they claim.
There is also a legal obligation on all adults NOT to make their account (password) accessible to minors; and only to allow minors access through their account if they are a legal guardian (or acting on behalf of one) and the minor is under constant supervision.
This is very much like existing censorship systems, but with three major differences: it is more transparent, there is legal recourse if the site fails to live up to its claimed rating, and there is an onus on adults to protect children (while not denying parents the right to allow their children access to material as they see fit).
Yes, there are ways around this. There are always going to be some sites that evade the law, just like there are porn shop owners that ignore the age of their patrons. There will be kids who "steal" adult accounts, just like they sneak into R movies.
But it is a great improvement on any system that is currently in place, and could be a suitable middle ground for all parties.
So this implant is intended for medical use, and subsequently identification? What does it offer that a bracelet with a MedAlert number or (to get high-tech) a smart card (on the bracelet) doesn't (in terms of medical detail)?
How does this assist in identification? The object of accurate identification is NOT to track ordinary people (except in aggregate), but to track specific people. Those who currently go to great lengths to avoid being identified, bypassing existing security and forging their credentials.
And, as usual, the Great Propaganda Machine assumes that because Joe Public can't remove an implant or modify it somehow, neither can a well funded terrorist.
Most disturbing, however, is the list of exceptions that will arise. Anyone who any government determines should be incognito will be able to get "fake" implants or avoid implants altogether. You don't want even a short range transmitter giving away the location of your crack troops, do you?
Just a casual FYI: My Hi-Fi has 4 buttons to control the CD tray and selection, another 4 to control the input source (casette, cd, tuner, aux), another 6 for various graphic equaliser options, 12 buttons to control the tapes, and one volume knob.
And just to complicate the issue, you won't get any sound out of the TV alone because its rigged to play through the aux ; similarly the TV isn't tuned to any channels, but accepts input on aux from the VCR.
The VCR, in addition to its 8 buttons, is programmable from an OSD.
This is not a typical household setup, not does it perform "a single function". What is important is that there are a limited set of functions most "users" use, and those are highlighted on the remote(s) in luminous blue (gotta love Tiwanese stuff ;p ).
The single most important part of designing an interface (for a computer) is to hide complexity without "hiding" it. Reduce the number of options at easy choice point to 7 +- 2. Don't do stupid MS stuff like hiding infrequently used options - users get confused ; it also means the user has a heck of a job investigating the full capabilities of the application.
An extension to this: your menu bar should have 5 to 9 menus, each with 5 to 9 items (possibly sub-menus), and each sub menu should have 5 to 9 items with NO submenus. A submenu should never invoke a dialog or be a "checkbox menu". In this manner you reduce the overall complexity to something a user can reasonably nagivate.
...and despite all this time, effort and money, most people still find computers complex to use.
My SO can pick up a remote control, figure it our without the manual, and operate the TV, VCR, and Hi-Fi. So can my parents. They are happy to set the message on their answering machine, program numbers into their phones, do combo-cooking with the microwave and generally use your average household technology without instruction ... but not a computer.
First you have to know about the idea of clicking with the mouse. The whole left-click / right-click thing which we take for granted and do 20000 times a day is NOT easy to catch onto for a new user. Once they have the idea, they still do know what to do.
"Start button? But its already started, why do I want to start it again?". How about the little icons on the taskbar? Any idea what they mean if you haven't been told? There's a deskpad with a notebook and pencil on it [looks like a writing application, but its the desktop]. Then a big blue "e" [here is South Africa we have a TV channel called "e" with a very similar logo]. Then a clock inside a square [that would be outlook].
When there IS a window open, there's three funny looking icons at the top right. Ask a new user if they can guess what they mean.
With the exception of international standard symbols (like the power symbol), most people can't guess the meaning of icons. Your average Word user goes on a 3 day course to learn the basics of clicking on the correct toolbar icon, when they could select a perfectly meaningful English word from the menu system.
The whole idea that GUIs are easy to use is a myth, as is the idea that icons are somehow more meaningful to users. These ideas have been forced down our throats by marketing droids and the odd technical writer who things (s)he knows his/her stuff.
I think what many people (including the author of the original article) fail to realise is that the hard drive icon is NOT part of the desktop, or even related to the desktop. It is the computer visualisation for getting up, walking away from your desktop and opening your file cabinet.
The two are very different, and both required. You cannot organise yourself effeciently with even a thousand desks - you need a filing cabinet. Conversely you can't work from a filing cabinet at all times - you need to take out a file, strew some pages around your desktop, and get on with stuff.
Sorry, but I have to disagree here. As much as I and may others dislike it, what you do in public is not protected by privacy laws, or even concepts.
Where you work and what you do (for a living) is, in almost all circumstances, public knowledge. If for no less reason than an arbitrary person on the street can observe that you usually drive a red Ford and always appear at a particular office block in the morning.
What the problem is here is that "they" are starting to invade our homes. "They" can uniquely identify us in private, and build a profile not of a group, but of an individual. THAT is invasion of privacy. If I watch TV screens in the window at a mall, I can't claim privacy. When I watch my TV at home, I expect my activities not to be tracked unless I have specifically been informed AND consented.
Basically, if you're on public property, your actions are public. On private property, they are private. On corporate property they are representing the company. But electronic media complicates the issue dramatically.
I can access private property (my home e-mail) from the physical location of corporate property. How is the line on privacy drawn then? Arguably (unless I have permission) I am committing fraud for using corporate resources for private gain (doing personal stuff on company time). Even if I have permission could the content of the private mail, if it were accidently disclosed, negatively affect the company? Being their physical property don't they have a right to "invade" my privacy (as in I can expect my actions and communications to be monitored).
You may agree or, more likely, disagree. But this is a gray area. The TV issue is related: public property (broadcast signals) being accessed from private property (my television in my house). Where's the line?
As much as this freaks me and others out, consider that you don't have much better luck with other media (shock, horror!). If you want to watch porno on TV this new system is going to let marketing know that. If you go down to your local bookstore and buy a Playboy, the clerk is going to know (and probably some of the other customers too). If you subscribe then their marketing division knows directly (your name, address, credit card ...), and the postman is sure to know as well.
The issue is no so much that we are being profiled, but that electronics offers better anonomity than real life, and we should benefit from that. As long as there is no way to identify the connection between a profile and an individual, few people should have problems with this.
There is a grey area of sufficient mass to sink the Titanic in there.
I don't believe in the existance of God. On the other hand I don't believe that God does not exist. Which in no way says that I believe God exists. I am agnostic in so far as knowing that it is impossible to prove (scientifically) that God exists or not.
The link you have supplied is the regular thological crap. Agnosticism is NOT "I don't know if there is/isn't/are/aren't God(s)", it is "I know that it is not possible to prove the existance or non-existance of God(s)". Atheism is NOT "I don't believe in God", it is "I believe there IS NO GOD". These are vastly different concepts, although often confused by virtue of being "opposite".
The typical position of an agnostic is therefore NOT to believe in a God (or Gods), but on the other hand not to believe that there are no Gods. In other words: They may or may not exist; all I know is I cannot use science to prove this one way or the other; therefore its not going to bother me.
"Agnostic" is not a word derived purely from the roots "a" and "gnostic". It has a distinct theological meaning (as do many other words, such as gnostic, which refers to a specific system of religious beliefs; agnostic certainly doesn't imply disbelief in or the anthesis of gnosticism). The linked article has about as much actual logic as saying that an aphid is not a phid (wtmb).
Remember, the opposition to a view is not necessarily the opposite.
Typically the various languages separate programs and utilities, and therefore function. But a logical grouping takes off of these into account.
Look no further than Freshmeat. Projects are classified and categorised. At some point you get to the source code for a particular project (as a tarball), at which point you are considering a single project.
Follow the same hierarchy for a project which has subprojects:
Main application make files
Utility application one section
Utility application two section
and so on...
Your source tree needs to have no resemblance to the final product. What is important is logical separation and navigation of source. That is why you should keep the applications separate at the top. Then keep the languages separate: even when it comes to JNI the languages don't work together, but cooperate across an interface. Even your code for a single language should be broken into directories according to its logical units (any cohesive library or application with a defined interface).
Your make process can ensure that all the sources are properly colated (either implicitly or explicitly by copying or using symlinks) and build into whatever form you want.
This issue of culture is (IMHO) and important factor working AGAINST GPL in the open source arena.
I know several companies (I work for one) that either explicitly or implicitly will not use GPL or LGPL software in their development (think libraries here, not tools). Not using GPL is obvious, but LGPL is more subtle: you don't have the option to integrate the functionality directly into your application, even if you want to.
Many licenses also force you to distribute part of your application in source form (the open sourced libraries, not your own code) or to prominently mention the use of the library, which tramples on poor little corporate egos.
While I believe in giving credit where it is due (especially when you are leveraging effort done by others are no charge to you), most companies can't take the "bad press" or general perceived humiliation of admitting to using free code.
So some think this is good, because they aren't scabbing off your efforts. True. And you're entitled to that opinion.
But it is also bad. OpenSource is about getting more eyes seeing the code, and more hands working on it. Companies that I have had experience with have no qualms committing changes back to open source, as long as they can avoid the marketting problems it may create. So if your library is 90% good for a particular use, corporate time and money may just go to filling in their 10%, which they give back.
Even if its only one in a hundred companies, its worth it. And judging by the project out there working on this basis ... its not that rare.
This is precisely my choice. And an important one.
I can make a library, or implement (say) a protocol I have designed. I know full well that many commercial enterprises will not use even LGPL in their applications (they will want to integrate the protocol fully), and are unlikely to support some arbitrary unknown protocol from Joe Q Public.
So instead I put the code under BSD license, so any individual or organisation can choose to use the code if they want.
Yes, I am at the mercy of MS & partners doing the embrace and extend thing, but MS has shown itself (in cases) to be incapable of that tactic if the market is already sufficiently standardized (they can't change HTTP because of Apache, and the haven't managed to corrupt XML yet).
Computer programs cannot be though of without considering "similar" works like books. A program represents an investment of time, effort and (usually) money. The final product is of interest or value to a user. This makes a program commercially viable as a trade product.
Given that programs are necessary, to force all of them to be free and/or open source would infringe on the rights of a (large) number of individuals to earn a living. Basically: no commercial viability, not a career option, no programs. Bummer.
Contrary to (unpopular) opinion, source code is not like a book. Binray code is like a book: its a finished, usable product. Should authors be forced to disclose their notes, the design of their plot, their character sketches? No. How about their "formula" for writing a captivating novel?
Points to ponder ...
Well said!
It is ultimately up to the programmer to decide how (s)he wants to see his/her code used. Fortunately for those of us who make a living from this soft of thing, RMS can't force us to give away everything we do for free ;)
Off topic
To supplement this line: a democracy is not about following the wishes of the majority, but about compromising in favour of a majority while protecting the rights of all minorities.
This is the thin dividing line between democracy and (political) communism.
Please check if you are using any software to which I have contributed (my time and effort, at no charge). If you are doing so, I would appreciate you coming over to do some of my gardening some time.
You see, I'm not so hot on the getting down and dirty side of life, but I'm a decent hand at coding. Either of which represents an amount of time and effort.
So if I choose to code up something (using my time and effort) and give it away at no charge, I won't appreciate being told under what rights I have to give it away.
In the same way as you doing your gardening (using your time and effort) should in no way imply that you have a requirement to do my gardening, just because you did your's for free.
What I'm trying to say is: I have rights over my creations. I have the right to make it closed source and sell it. I have the right to destroy it and never let anyone know about it. I have the right to make it freely available to anyone, for any purpose. And I have the right to put it under the GPL.
And unless I give someone the right, they have no right to tell me what to do with my property. Whether you consider IP property or not is actually irrelevent - my creation is the product of my time and effort.
So if you don't like my right (when applied to my "property") to restrict your rights ... then kindly remember that you don't have the right to restrict my rights when your capabilities are concerned.
See you in the garden on Saturday ...
Hopefully we will live in a world where we have far more freedom than exists in the States; where the president isn't awarded god-like power (at least in terms of persuasion), and where the rights of natural humans EXCEED those of juristic persons (companies).
OTOH ... the States is still vastly better than most places on earth ...