These is no technical requirement for dot files. If the entire community decided to standardise on ~/etc, it would happen.
The general theory of/etc,/usr/etc and/usr/local/etc is quite simple. System configuration goes into all of these directories (no user config). Configuration needed at bootup goes into/etc. Configuration needed for OS-default applications goes in/usr/etc, which is available once/usr (containing the OS-default applications) is mounted. Configuration for application you have installed specific to your system (stuff that should be in/usr/local) goes into/usr/local/etc.
The article is not proposing a central configuration file, but a standard for configuration. That would be like saying all application MUST store their configurations in a specific directory, and they must all use the same file format (say XML). Storing all configuration files in the same directory is not the same as storing all configuration in one file.
The benefit of a common location and format is that every app or admin knows where to look for files, and how to interpret them. The structure of each file is identical, so you don't need to know if you use #,//, ' or $ for comments, and whether each line must start with a TAB or end with a ; . What each file says is still different, its just how it says it. Currently trying to work with config files on Linux is like being in a building and trying to talk to people, but everyone is in a different room and talking a different language. Standardize the language and the location, and you only have to content with understanding what is being said.
Incidently, system.dat is not a security problem. In Unix terms that file is r/w by root only, and access only occurs through a kernel-level API. So "cracking" system.dat is no more or less hard than "cracking" shadow.passwd.
First, XML is not a silver bullet. The thing this article screamed was not "XML" but "API". Define the application programming interface for a library, and stop thinking that each application must directly access the native data.
Second, XML Schema is a definition for an XML language, not a document described in a particular XML language. XML is a meta-language, you have to MAKE a dialect using a schema or DTD first. XML Schema could not, for example, include primitive types for IP addresses (very common in config files), or validation constraints for integer values.
Third, XML parsers are no-where near as ubiquotous as you would like to believe. To date there are no (zero, zip, nada, nothing) fully compliant XML parsers. Read the XML spec. carefully and understand just how many IFs and BUTs there are to creating a parser. Xerces and MS's parsers are the closest, but still have a number of problems. Expat-derived parsers happily handle a large subset of XML, but not everything. A vast number of parsers out there ignore the DTD, which means they cannot handle entities (which is a big issue).
Finally, there is nothing intrinsically human-readable about XML. This is common bullshit sprouted by those who haven't actually considered the requirements for human understanding. A simple.ini-style line delimited key=value is the most readable and understandable (from a psychological viewpoint) configuration format.
A brilliant article, and a subject which I have tried before (with little success) to broach with various OpenSource developers. Unfortunately the comments demonstrate the lack of understanding that is all too common in the free software world: an inability to distinguish between apis/formats and software implementations; and an unwillingness to move to a more user friendly system.
GConf and Webmin, for example, are not solutions that address the problem posed by the article. Other comments completely lose the plot: this is about a common configuration format which can use metadata to provide for configuring just about any application, it is not about creating an all-encompassing configuration that will give settings to all applications everywhere for all time.
Gconf is half of the solution at best. It provides a library (common abstraction) for accessing the data. But an application still has to have explicit knowledge of the data in order to act on it. A configuration framework describes this knowledge to allow any compliant application to act on it.
Sometimes an example is worth 1000 pictures (and hence about 1000000 words), so consider a simple packet filtering application with an ACCEPT list and a DENY list, which can listen on several interfaces.
Such an application would have a meta-data configuration file (say/etc/conf/meta/filter.cfg) which specifies:
section name=interface count=multiple type=ipv4 ; section name=accept count=multiple type=cidr ; section name=dent count=multiple type=cidr. Now any application can access the packet filter's meta-data file, and the real configuration file (say/etc/conf/filter.cfg), and understand the meaning, to a degree, of the configuration. The types "ipv4" and "cidr" will have to be primitives for the configuration framework.
Thus a general configuration application could present a tree which has three branches (interface, accept, deny), each of which displays a screen with a list. Appropriate entries can then be added, modified or removed, reconfiguring the packet filter without the configuration application having any prior knowledge of the filter's configuration or requirements.
With adequate forethough (for the categorisation and types required) such a system can be extremely powerful. A single configuration library can be used by the application, as well as GUI and CLI configuration clients. You could easily have a command in a script: config pktfltr add -section interfaces -value 1.2.3.4.
A common library like this can also provide powerful features that a lot of applications lack, like local (user) settings which override global defaults. The library can maintain global, group and user configurations for each application, and getting/setting preferences will take the overlays into account.
Implementing such a system would also provide an ideal opportunity to introduce configuration versioning. CVS (for example, or arch, which includes directory versioning) could be used to maintain various versions of the configuration files in/etc/conf.
Arguments about diversity are largely moot. The data format is independant of the data in any well-written program..INI files, Bind-style files, XML files and SAMBA files can all represent the same information, but they look different. Some are arguably more efficient in some situations. Even the feared Windows registry has the same functionality... it just makes the (fatal) error of storing everything in a mostly inseparable datastore (sortof like an/etc/conf directory in which you can't treat the various files separately).
This is a suggestion which needs to be followed through, and supported by the community.
Re:Was that so complicated?
on
What is .NET?
·
· Score: 2
Hi. I'm afraid my point wasn't clear, and you are taking aim at the side;) You certainly can't do something in Java that you can't do on the native platform (that would be impossible).
My point was that when you have a cross platform library which itself does the rendering on all platforms, you can do things that you can't do with an equivalent library which delegates to native components. This primarily involves the behaviour of the widgets, rather than their look.
A classic example of view problems occurs in Gtk and WxWindows, where it is very difficult to get a button on Win32 to render itself with anything but a gray background (a normal SetBackgroundColour() won't work). WxWindows is considered to be one of the most mature cross-platform GUIs, yet it suffers from this sort of problem.
In terms of behavioural problems, each of the systems (win32, motif, mac) have their own logic for component layout, order of rendering, and order of message delivery to the widget. In order to make a reliable cross-platform GUI system these features need to be deterministic and reliable across platforms.
When delegating to native components this becomes a very complex task, and involves a significant amount of processing (but not drawing) overhead. Using component emulation a-la Java and WxUniversal, you reverse the situation. You have a reliable, deterministic behaviour, which requires little tweaking or additional overhead to make it cross-platform... but you have to rendering the graphics yourself.
I think society will gain more in the long run from the creator (more fruits of his labors) by respecting his choice
I am inclined to agree with you. But you are talking about the creator, not the owner. What was once one, is now a complex legal minefield.
Scenario 1: creator passes into the Great Beyond, and what happens? Do the heirs get to keep making money from the creation? Or should it become public property then? At the moment international copyright law allows copyright to extend for 75 years after death to designated heirs.
Scenario 2: creator sells (or is coerced into relinquishing, say because he is employed by them) copyright to a company. Now what? Companies as a rule don't give a shit about society; this situation is getting worse as the persuit of the almighty buck leads to less morality in industry. Which is precisely what this discussion is about: companies have reached the stage that they firmly believe a threat to their POTENTIAL income is an illegal act.
Imagine if that was true. It would be illegal to fire someone, because that is a threat to their potential income;)
Copyright is still easy to deal with in a fair way where idividuals are concerned. But companies (which aren't expected to die after a reasonable amount of time) complicate the issue.
Re:Was that so complicated?
on
What is .NET?
·
· Score: 2
Oh Jesus, you're an arrogant bastard.
Thank you.
Sun needs to concentrate less on a perfect cross-platform GUI system and more on a functional system.
An my contention is precisely the opposite. The OpenSource world in general is obsessed with optimization, and couldn't give a shit for sound practices of software engineering. If the "real world" was so concerned about response time from their interfaces, why is everyone jumping onto the deliver-it-with-a-browser bandwagon?
I have written many Java programs that simply work on Solaris, Linux, and Windows; the require no tweaking of the GUI or the underlying logic. From a commercial developer's point of view, that sort of reliability is orders of magnitude more important than "Oh my God, Java takes 8 additional seconds to load, and the menus are at least 250ms slower on popping up" (figures approximate for MagicdrawUML versus Visio).
rightful owner? That is the crux of the matter, but you are using it as a foregone conclusion.
Copyright and parent laws were created to balance the rights of individuals and the rights of society. An individual who stands to gain nothing from creating is unlikely, or less likely, to create. So too an individual who creates by still stands to gain nothing has no incentive to reveal that creation, or its details. On the other hand society stands to benefit from most creations, and to benefit even more when the details are available.
So laws were created to protect the individual's creations while ensuring the society could benefits from them immediately and in the future. It used to be an unchallanged assumption that freedom of knowledge was the road to humanity's future.
The issue we currently face is: where should the line be drawn on the rights of copyright holders? This is not an easy balance to find. On the one hand you have industry, whose game settings are "Allow economic victory". On the other side are some individuals. Politicans and capatalists are somewhere in the middle.
Java will support parametised types, not templates. C++'s solution is a hack, and most people know that. True language (and VM) support for parametised types will not involve any binary bloat. In a way you can think of it as having a "object type" attribute and doing an "instanceof" to check that the type is right.
Re:Was that so complicated?
on
What is .NET?
·
· Score: 3, Insightful
For instance the WindowsForms which are natively compiled components for building client-side applications. If Microsoft didn't do this, the client apps would probably have the same runtime performance problems that AWT and Swing has.
Please understand what you are talking about before repeating someone else's bullshit. AWT is natively compiled components. Like any system which must bind to libraries in another language, there are parts in the relevant language, and peers in native code.
Swing uses the bare minimum of native components and creates its own widgets. This gives you the power to do things you can't do with Windows (and ComCtl32), Motif, Mac, whatever. Swing is not slow in and of itself: try running the program for a while and accessing all the GUI functionality, then all of the classes will be loaded and the JIT will have compiled most bytecode, and you can use Swing happily.
FYI: if you want to improve Swing performance and are prepared to lose a little time at startup, force load all the Swing classes you use (using forClass() ), and unJAR the JRE classes.
Another FYI: why don't Sun do this if it is so obviously superior? Because you can't. There is no cross platform GUI system which uses native widgets and can maintain integruity across platforms. Those which seem to go to extreme lengths to control or modify (by wrapping) the native widgets to bring them in line with their view of the world, and still end up breaking.
Try writing something in Java or WxWindows Universal, and you will get identical GUIs on all your platforms. Go for WxWindows (normal) or Qt, and you have issues - and these are some of the best there are. Don't even talk about Gtk until you've used it on Win32 and discovered its idiosynchrosies.
it should be the responsibility of the web server to block remote sourcing if they don't like it
How exactly does one do this? You can't deny access based on IP, for example, and there is no intrinsic support in HTTP or browsers, which leaves you with two possible hacks: correlate requests for graphics, etc, with recent page requests; and use cookies.
The first hack doesn't work, in particular because of caches. Your browser may still have the page cached, but not the graphic.
The second hack doesn't work because many people disable cookies.
I think the best analogy comes from print media. You can quote a small amount from elsewhere, as long as you credit the original source (quote by author in media). You can reference other material (see book, page). But including copyrighted work which is a substantial part of another publication (either in quantity or content) and especially when there is no explicit indication that it is not your own work, is infringement.
You're absolutely right. I was considering whether or not to raise the point about multiple NICs, but then for a fault tolerant system you should have them anyway from a redundancy point of view.
The question of necessity (in terms of bandwidth) comes down to the client-server design rather than the database design. The database server may provide lots of information lists to the client (say, a customer list, and then a query will return detailed customer information) which will require a huge amount of bandwidth if there are a lot of clients. OTOH the clients may be primarily interested in correlative queries, in which the database server is doing a lot of processing to come up with a relatively small answer.
I think the main issue was that the original poster seemed to make the mistake of thinking gigaBYTE ethernet, not gigaBIT, and implying that the networking would not be a bottleneck to the disks.
First, you need to consider that because of data locality, you are never going to reach the STR you are pondering. Queries would have to magically occur in such a way that the disk load was perfectly balanced between all drives. Your worst case STR is therefore 43Mb/sec, ASSUMING you benchmarked the STR on random access rather than sequential access.
Second, as many others have said, use RAID0+1 ; RAID5 has overheads that (can) involve other drives in the chain.
Third, your Gb ethernet is gigaBIT. That provides for a maximum throughput of 125Mbyte/sec on a switched network. To improve on this you could use multiple Gb NICs... but they are on the PCI bus, along with the RAID adapters. This doesn't necessarily halve performance (it could in the worst case scenario), but the degradation depends on the size of the request/response versus the data that must be retrieved and processed.
Forth, you have a couple of more obvious software overheads. Issuing a read or write takes time. Software has to interpret the query, formulate the strategy to come up with a solution, and make read requests. Those requests are processed by file system handlers, which translate into raw disk operations. This means your file system and database software are adding a lot of overhead and latency that will reduce the STR.
Basically you are wanting a heck of a lot of memory, and a vast amount of processing power to keep up with the potential of the hard drives.
It would seem that the terminology being used is somewhat confusing. "Linking" appears to indicate a direct URL reference in (say) an IMG tag, rather than a "link to a page" (A tag).
Essentially there is no problem with providing a link to the original page, where the image will be displayed in context, but pulling the full image out of context is an issue.
From previous legal challanges and discussions, it would seem that "framing" is much less clearly defined. Providing a banner which indicates that you are supplying content as a proxy (or similar circumstance) appears to be okay, but having a site embed content from another site (say in another frame) where there is no indication that the content is not yours, would be considered framing.
This tends to happen most often when the site with the content has frames, and you have frames (in both cases, HTML frames), and you can link directly to one of their frames without the rest being displayed.
The Koeburg facility on the Cape west coast is still operational. A reactor glitch and some sort of stuff up at the national grid switch in the middle of the Cape was responsible for that massive power failure in Cape Town last year. That facility produces 3200MW, larger than the coal stations in the Transvaal.
The second reactor has always been experimental, and never produced power commercially. It was shut down some time ago. In light of it being 26 years old and having two safety "incidents" recently due to low maintenance budget, there are proposals to close Koeburg in the near future (2008-ish IIRC).
You're (not 'your') an idiot;) Grade 12 Geography. First world nations include those you listed, EXCLUDING the USSR, plus most of Europe, Austalia, Japan and others. Second world is a category which was reversed for the USSR and communist nations! Third world included all underdeveloped nations. Incidently there are also "forth" and "fifth" world classifications, which served to break up the "third world" category more precisely.
It is an issue of some contention as to whether SA is "first" or "third" world. It is generally considered to be a duality - much of our infrastructure and cities is first world, but the problems of poverty and service delivery are typical of third world nations.
Let's see. In SA we have (1), (2) [at least at local/national government level, and for many people], (3), (4), (5), (6), and (8). (7) is debatable because while there is legal respect for individualily, many ethnic groups believe strongly in an "elder", even if they have the right not to. (9) depends on who you ask - the strongest split in SA is still along racial lines.
Oh dear, you must be an American. Try looking at http://www.polity.org.za/ which has information about SA, and links to most of the government web sites. We don't exactly need free hosting on Geocities; in fact we have already hosted an online debate on electronic commerce regulations (which is far more forward-looking than most developed nations).
Oh, by the by: [nucleartourist.com] (South Africa) ESKOM is the 5th largest utility in the world. They operate the 2 Koeburg reactors, each with a capacity of ~900 MWe. They do have a page listing their generating facilities with capacity.
ESKOM also developed and are prototyping pebble-based molecular reactors, which Germany and France gave up (citing as impractical) nearly two decades ago. These promise to provide cheap, clean and safe energy to anything up to a small city, and can be located where needed. They promise to be a solution to the energy problem in the third world.
South Africa is fairly unique amongst developing (esp. African) nations. We have an excellent infrastructure for transportation and communication in most parts of the country. While many people do not have their own telephone lines, there are ongoing projects to remedy this situation.
But far more interesting is the fact that these are a huge number of people living in ghetto-type conditions with no basic services, who are using the cellular networks to communicate. This goes to show that there is money and intent available for electronic communication.
There are several existing projects to get PCs into underdeveloped schools. In fact the hardware side of the projects is quite successful, but they are struggling because of the cost of software and the lack of teachers with computer experience. Linux is not suitable in such environments until it is easy to install and administer with little or no experience.
One of SA's biggest barriers to bringing "computing to the masses" is the commercial attitude: SA is extremely loyal to Microsoft, and to leading-edge technology. Technology more than a couple of years old becomes nearly impossible to get. Few wholesalers stock chips under a Celeron/Duron 800, or RAM chips less than 128Mb. They perceive that there is money to be made from companies, and not from supplying cheaper hardware to more "charatible" causes.
SA suffers from a "nothing but the best" syndrome, which affects development. It is generally unacceptable to provide second-class solutions as an interim measure while working on a long-term solution. This means that, for example, a project to get computers into schools will involve building a secure building for the computers (many poor schools are prefab or have degraded buildings), and the provision of networked multimedia computers.
Having said this, it is obviously not the way to go. There needs to be an attitude change and an acceptance of older technology, alternative technology or interim solutions.
Actually the availability of communications is not important in the use of computing in developing nations. Computers can be used "offline" as teaching aids, and this is probably where investment should be targetted. Education standards in SA are dropping, there is a massive adult illiteracy rate, and computing skills (required in many industries) are lacking.
An obvious and useful proposal would be to develop and mass produce cheap hardware which can run OpenSource software, and start developing (locally) teaching aids in all national languages (we have 11 of them :
Incidently... the mining sector only accounted for 6% of GDP in 1999 (worldinformation.com), Tourism for 4% and agriculture for 4%. What makes SA an economic power in Africa is its NON-reliance on mineral resources.
I could be a little out of date (maybe even a lot;) ), but last time I checked you could do a lot of calming of DoSing by implementing proper packet filtering on routers.
IIRC most DoSing relies on the kiddie hiding their source address (so that they can't be traced). So ensure that the router closest to the kiddie knows all the IPs it is allowed to accept, and rejects (and logs) all others.
This puts an onus on ISPs to handle the situation. Any ISP which doesn't react immediately to a DoSer from it or a downstream stands to lose (all of) its uplink(s).
Most port handling equipment can handle quite complex filtering on its own, knowing the IP allocated to a port and filtering all packets without that as its source. Port handlers typically forward to a router anyway, so its easy for an ISP to say "that interface talks to that rack, which can use IP range X to Y, so filter everything else". Immediately your script kiddie is limited to faking addresses of other users in the range.
This screws up a number of DDoS attacks I know of (where the reply to an unwitting host causes shit for the replier), and makes it a lot easier to trace the kiddie at least to within a limited number of possibilities.
If the ISP supplies a link to another ISP it must ensure it toes the line. Bulk links to corporate customers or anyone with a range of IPs (rather than just one) at the other end of the link can usually be handled like dial-ups: port handlers filter out bad source IPs.
Does anyone know of technical and/or political reasons why this can't work? If there are no technical problems then maybe an IETF policy committee needs to make it a standards issue.
The fact that you aren't prepared to stand up to your manager is the first sign of a problem. You have to make management understand that you are (I assume) a professional. Development or (hopefully) software engineering is your career, for which you are educated, and that in such areas management does NOT have the required knowledge to act.
In no other technical profession can management dictate HOW the job should be achieved. They can set budgets and deadlines, and assist in planning, but they do not have the liberty to force a domain expert to act in a certain way.
This needs to be made more clear to software managers. Software is difficult to write and to maintain. Even though most contracts seem watertight, there is an element of liability implicit in the sale of custom-developed software, which makes YOUR organisation responsible. And as the software engineer someone is going to shit on YOUR head when things go wrong... not the manager's.
XP is divided into four major areas of activity: Planning, Designing, Coding, Testing. The project starts with requirements analysis and an architecture or framework for the entire system. Emphasis is placed on simplicity and preventing feature creep. Then it goes into an iterative development phase in which the emphasis is on rigerous unit testing and feedback, ensuring that code works, and problems are detected early.
The value proposition of XP is risk control: feedback provides a good idea of problem areas and allows for handling them when they arise, and iterative development ensures that feature creep and miscommunicated requirements cause limited damage.
You are correct that XP is not that new. It bears many similarities to the Rational Unified Process, but is in no way related to RAD. XP stresses the importance of an underlying architecture and extensible design, before coding is started.
Would you care to expand on what you mean by "REAL Software Engineering texts"? Most people seem to believe that scientifically provable methodoligies are the only option for software engineering... how unfortunately that it was recently proved that it is impossible to reliably estimate software complexity, which is a core requirement for software engineering.
Or perhaps you have forgotten that software engineering, not other engineering disciplines, does not concern itself solely with technical aspects of the software, but business aspects as well: resources, deliverables and schedules.
XP is significant in being one of the least presumption of design methodologies. It does not require any knowledge, on the part of the programmer, of the business processes of the end user. Many software engineers think this is wrong, without realising that business process engineering is a sector-specific activity and an entire field of study; not something a software developer can pick up in a few weeks in order to do requirements analysis.
Cooper gives an example of a building architect interacting with the customer and the engineer to determine all of the building requirements before building starts. What he fails to take into account is that the building is a framework - as long as it has the right size, foundations and number of floors and elevator shafts, it is going to support a huge variety of functions.
Once the shell is complete, other teams move in to customize bits within the building. You can vary the number of elevators available within the limits; make them faster or slower, or only stop on certain floors. Each floor can be divided up with hardboard walls, plumbing and electricity get installed into ducts, aircon is added, carpetting, and finally furniture and fixtures. These don't need to be designed up front.
XP, unlike non-iterative methodologies, happily delays these details until later. RAD, by comparison, starts with the wall art and curtains, adds some furniture and walls, and then falls flat because it doesn't have a building.
There seems to be a general perception in the middle/upper class that poverty is the fault of the poor for not uplifting themselves. This is a good sign of a complete misunderstanding of the socioeconomic system.
Let's start with minimum wage. You're right: its a minumum. It has nothing to do with the cost of living, but with the cost of surviving. It is set according to the requirements of a statistically average poor household (2.5 kids, high density housing, 1 working parent), and should allow them to maintain basic human standards of living according to the International Declaration of Human Rights.
So why should a bunch of capatalists be interested in such bullshit? Why don't they just get skills and improve their lives?
Because you, working on your expensive computer in your suburban home, require unskilled labour. Because you aren't prepared to fix your own potholes, take your garbage to a landfill or recycling site, sweep the streets, mow the verges, or watch for cracked beer bottles on a production line and smash them so that you can enjoy a cold one at the pub.
And because capatalists put too much emphasis on skill, and undervalue basic services of this nature, the system can't work without intervention at a political level.
The paradox that arises is that you can train unskilled people, but that leaves a vacuum for unskilled labour and an abundance of low-skill labour. The economic of supply and demand kicks in, and you end up with situations that have been seen in Germany and the far east: production line workers (low/moderate skill) earning less than menial labourers (street sweepers, etc), because no-one with skill is prepared to do such an arbitrary job.
An ecnonomic system, like a political system, is a compromise between government and individuals. Some individuals want complete equity in distribution, some want complete anarchy. The compromise is the point at which restrictions are placed: with capatalism the point is close to anarchy.
This compromise is needed because in a pure capatalist society, those with money can dictate to those without. Even a highly skilled individual cannot earn a good salary if companies are not prepared to pay one. Competition and demand only work to a limited extent: if all companies recognise that they can get a resource cheaper, they will force such a response from the market.
Notice how consumers are generally unable to apply pressure to large companies, but the reverse is not true. Microsoft, Sony, and Universal come to mind. When dealing with necessary resources (like a job) as opposed to optional or luxury items, the laws of supply and demand largely go out of the window.
In other words, the job of a capatalist government is (amongst others) to ensure that there is an unlimited ability to grow money, but that must be balanced against the rights of individuals to earn money, and the cost and value of services that need to be provided to society. The prevention of collusion and the use of minimum wage are extremely effective in creating such a balance.
Democracy is not about listening to the rule of the majority. It is about accomodating the majority while protecting them and the rights of all minorities. Capatalism is inherently at odds with democracy, which is why most first world countries tend towards socialism (especially in Europe).
Hi. Just FYI, out performance testing results. We have three implementations of this server: NT IO-Completion ports, select() and multi-threaded.
Testing was done using n identical clients, all flooding synchronous requests. i.e. each client sits in a "send, wait for reply" loop. The bottleneck is network bandwidth - we get sub-optimum performance except on Gb ethernet.
The nature of our server is such that max. performance is reached at at 8-12 conenctions. The multi-threaded server has the best performance out to 20-25 connections. IO completion ports scales out to 500 connections, dropping only 3% in performance (compared to 12 conenctions). select() never tops the scales, but is consistently about 1% behind IO completion ports out to 120 connections, then drops back to 10% behind out to 250 connections, then drops off horribly.
I will readily admit, however, that our implementation using select() could be more efficient. Even so, in architectural benchmarks it doesn't fare well beyond about 400 connections in a server doing IPC/RPC type transactions.
First, I said Apache-style architecture, not Apache architecture. This means a pool of independant entities all of which block on a common kernel signal, and the first one to obtain the signal takes and processed the associated request synchronously with respect to itself.
Whether threads or processes are used is largely academic, and is not an architectural consideration (it is an implementation consideration). On most Unix systems threads are not first-class entities in the scheduling system, and cannot be considered for high performance applications. Win32 systems on the other hand support multithreading as well as multiprocessing natively, and Apache itself could be implemented as efficiently using threads as using processed (possibly more so, because win32 doesn't have copy-on-write process creation).
Java is perfectly capable of supporting several architectures other than thread-per-connection. Not to mention that Apache itself is a thread-per-connection (or process, if you wish to draw a distinction); in which threads/processes are reused, and a limitation is configured on maximum simultaneous threads/connections.
The most significant thing about the Apache architecture is that there is no controller process which listens on the server socket and assigns new connections to pooled processes. Instead, each process is a peer, and listens for new connections when it can. This enhances both performance and stability. This is what I was meaning when I referred to an "Apache-style architecture".
Java is able to scan in a non-blocking manner for new connections, or for data on a connection. As such it can implement pseudo-select() functionality. JDK1.4 in fact has the nio package which implements a Java equivalent of select().
Finally, in connection with your claims about performance, I said "average client-server application". You have quoted me an extremely contrived benchmark. Not only is the serving of 1 byte files unreasonable as an "average" application, but a web server is not an application server, but a file server.
Quote me a benchmark on a Java server versus a similarly-architeced C++ server in which there is some serving of static content, but primarily (say 70%?) involves server-side processing (even page generation would be reasonable), and I'll be more inclined to accept your view.
Slashdot Mirror
At the risk of /.'ing my ISP ... take a look at a doc on my home page which goes into a whole lot more depth than my Slashdot post.
I tried to get an effort like this off the ground about 4 years ago, with little success. I'm still interesting in playing with it though.
These is no technical requirement for dot files. If the entire community decided to standardise on ~/etc, it would happen.
The general theory of /etc, /usr/etc and /usr/local/etc is quite simple. System configuration goes into all of these directories (no user config). Configuration needed at bootup goes into /etc. Configuration needed for OS-default applications goes in /usr/etc, which is available once /usr (containing the OS-default applications) is mounted. Configuration for application you have installed specific to your system (stuff that should be in /usr/local) goes into /usr/local/etc.
The article is not proposing a central configuration file, but a standard for configuration. That would be like saying all application MUST store their configurations in a specific directory, and they must all use the same file format (say XML). Storing all configuration files in the same directory is not the same as storing all configuration in one file.
The benefit of a common location and format is that every app or admin knows where to look for files, and how to interpret them. The structure of each file is identical, so you don't need to know if you use #, //, ' or $ for comments, and whether each line must start with a TAB or end with a ; . What each file says is still different, its just how it says it. Currently trying to work with config files on Linux is like being in a building and trying to talk to people, but everyone is in a different room and talking a different language. Standardize the language and the location, and you only have to content with understanding what is being said.
Incidently, system.dat is not a security problem. In Unix terms that file is r/w by root only, and access only occurs through a kernel-level API. So "cracking" system.dat is no more or less hard than "cracking" shadow.passwd .
First, XML is not a silver bullet. The thing this article screamed was not "XML" but "API". Define the application programming interface for a library, and stop thinking that each application must directly access the native data.
Second, XML Schema is a definition for an XML language, not a document described in a particular XML language. XML is a meta-language, you have to MAKE a dialect using a schema or DTD first. XML Schema could not, for example, include primitive types for IP addresses (very common in config files), or validation constraints for integer values.
Third, XML parsers are no-where near as ubiquotous as you would like to believe. To date there are no (zero, zip, nada, nothing) fully compliant XML parsers. Read the XML spec. carefully and understand just how many IFs and BUTs there are to creating a parser. Xerces and MS's parsers are the closest, but still have a number of problems. Expat-derived parsers happily handle a large subset of XML, but not everything. A vast number of parsers out there ignore the DTD, which means they cannot handle entities (which is a big issue).
Finally, there is nothing intrinsically human-readable about XML. This is common bullshit sprouted by those who haven't actually considered the requirements for human understanding. A simple .ini-style line delimited key=value is the most readable and understandable (from a psychological viewpoint) configuration format.
A brilliant article, and a subject which I have tried before (with little success) to broach with various OpenSource developers. Unfortunately the comments demonstrate the lack of understanding that is all too common in the free software world: an inability to distinguish between apis/formats and software implementations; and an unwillingness to move to a more user friendly system.
GConf and Webmin, for example, are not solutions that address the problem posed by the article. Other comments completely lose the plot: this is about a common configuration format which can use metadata to provide for configuring just about any application, it is not about creating an all-encompassing configuration that will give settings to all applications everywhere for all time.
Gconf is half of the solution at best. It provides a library (common abstraction) for accessing the data. But an application still has to have explicit knowledge of the data in order to act on it. A configuration framework describes this knowledge to allow any compliant application to act on it.
Sometimes an example is worth 1000 pictures (and hence about 1000000 words), so consider a simple packet filtering application with an ACCEPT list and a DENY list, which can listen on several interfaces.
Such an application would have a meta-data configuration file (say /etc/conf/meta/filter.cfg) which specifies:
section name=interface count=multiple type=ipv4 ; section name=accept count=multiple type=cidr ; section name=dent count=multiple type=cidr. Now any application can access the packet filter's meta-data file, and the real configuration file (say /etc/conf/filter.cfg), and understand the meaning, to a degree, of the configuration. The types "ipv4" and "cidr" will have to be primitives for the configuration framework.
Thus a general configuration application could present a tree which has three branches (interface, accept, deny), each of which displays a screen with a list. Appropriate entries can then be added, modified or removed, reconfiguring the packet filter without the configuration application having any prior knowledge of the filter's configuration or requirements.
With adequate forethough (for the categorisation and types required) such a system can be extremely powerful. A single configuration library can be used by the application, as well as GUI and CLI configuration clients. You could easily have a command in a script: config pktfltr add -section interfaces -value 1.2.3.4 .
A common library like this can also provide powerful features that a lot of applications lack, like local (user) settings which override global defaults. The library can maintain global, group and user configurations for each application, and getting/setting preferences will take the overlays into account.
Implementing such a system would also provide an ideal opportunity to introduce configuration versioning. CVS (for example, or arch, which includes directory versioning) could be used to maintain various versions of the configuration files in /etc/conf.
Arguments about diversity are largely moot. The data format is independant of the data in any well-written program. .INI files, Bind-style files, XML files and SAMBA files can all represent the same information, but they look different. Some are arguably more efficient in some situations. Even the feared Windows registry has the same functionality ... it just makes the (fatal) error of storing everything in a mostly inseparable datastore (sortof like an /etc/conf directory in which you can't treat the various files separately).
This is a suggestion which needs to be followed through, and supported by the community.
Hi. I'm afraid my point wasn't clear, and you are taking aim at the side ;) You certainly can't do something in Java that you can't do on the native platform (that would be impossible).
My point was that when you have a cross platform library which itself does the rendering on all platforms, you can do things that you can't do with an equivalent library which delegates to native components. This primarily involves the behaviour of the widgets, rather than their look.
A classic example of view problems occurs in Gtk and WxWindows, where it is very difficult to get a button on Win32 to render itself with anything but a gray background (a normal SetBackgroundColour() won't work). WxWindows is considered to be one of the most mature cross-platform GUIs, yet it suffers from this sort of problem.
In terms of behavioural problems, each of the systems (win32, motif, mac) have their own logic for component layout, order of rendering, and order of message delivery to the widget. In order to make a reliable cross-platform GUI system these features need to be deterministic and reliable across platforms.
When delegating to native components this becomes a very complex task, and involves a significant amount of processing (but not drawing) overhead. Using component emulation a-la Java and WxUniversal, you reverse the situation. You have a reliable, deterministic behaviour, which requires little tweaking or additional overhead to make it cross-platform ... but you have to rendering the graphics yourself.
I am inclined to agree with you. But you are talking about the creator, not the owner. What was once one, is now a complex legal minefield.
Scenario 1: creator passes into the Great Beyond, and what happens? Do the heirs get to keep making money from the creation? Or should it become public property then? At the moment international copyright law allows copyright to extend for 75 years after death to designated heirs.
Scenario 2: creator sells (or is coerced into relinquishing, say because he is employed by them) copyright to a company. Now what? Companies as a rule don't give a shit about society; this situation is getting worse as the persuit of the almighty buck leads to less morality in industry. Which is precisely what this discussion is about: companies have reached the stage that they firmly believe a threat to their POTENTIAL income is an illegal act.
Imagine if that was true. It would be illegal to fire someone, because that is a threat to their potential income ;)
Copyright is still easy to deal with in a fair way where idividuals are concerned. But companies (which aren't expected to die after a reasonable amount of time) complicate the issue.
Thank you.
An my contention is precisely the opposite. The OpenSource world in general is obsessed with optimization, and couldn't give a shit for sound practices of software engineering. If the "real world" was so concerned about response time from their interfaces, why is everyone jumping onto the deliver-it-with-a-browser bandwagon?
I have written many Java programs that simply work on Solaris, Linux, and Windows; the require no tweaking of the GUI or the underlying logic. From a commercial developer's point of view, that sort of reliability is orders of magnitude more important than "Oh my God, Java takes 8 additional seconds to load, and the menus are at least 250ms slower on popping up" (figures approximate for MagicdrawUML versus Visio).
rightful owner? That is the crux of the matter, but you are using it as a foregone conclusion.
Copyright and parent laws were created to balance the rights of individuals and the rights of society. An individual who stands to gain nothing from creating is unlikely, or less likely, to create. So too an individual who creates by still stands to gain nothing has no incentive to reveal that creation, or its details. On the other hand society stands to benefit from most creations, and to benefit even more when the details are available.
So laws were created to protect the individual's creations while ensuring the society could benefits from them immediately and in the future. It used to be an unchallanged assumption that freedom of knowledge was the road to humanity's future.
The issue we currently face is: where should the line be drawn on the rights of copyright holders? This is not an easy balance to find. On the one hand you have industry, whose game settings are "Allow economic victory". On the other side are some individuals. Politicans and capatalists are somewhere in the middle.
Java will support parametised types, not templates. C++'s solution is a hack, and most people know that. True language (and VM) support for parametised types will not involve any binary bloat. In a way you can think of it as having a "object type" attribute and doing an "instanceof" to check that the type is right.
Please understand what you are talking about before repeating someone else's bullshit. AWT is natively compiled components. Like any system which must bind to libraries in another language, there are parts in the relevant language, and peers in native code.
Swing uses the bare minimum of native components and creates its own widgets. This gives you the power to do things you can't do with Windows (and ComCtl32), Motif, Mac, whatever. Swing is not slow in and of itself: try running the program for a while and accessing all the GUI functionality, then all of the classes will be loaded and the JIT will have compiled most bytecode, and you can use Swing happily.
FYI: if you want to improve Swing performance and are prepared to lose a little time at startup, force load all the Swing classes you use (using forClass() ), and unJAR the JRE classes.
Another FYI: why don't Sun do this if it is so obviously superior? Because you can't. There is no cross platform GUI system which uses native widgets and can maintain integruity across platforms. Those which seem to go to extreme lengths to control or modify (by wrapping) the native widgets to bring them in line with their view of the world, and still end up breaking.
Try writing something in Java or WxWindows Universal, and you will get identical GUIs on all your platforms. Go for WxWindows (normal) or Qt, and you have issues - and these are some of the best there are. Don't even talk about Gtk until you've used it on Win32 and discovered its idiosynchrosies.
How exactly does one do this? You can't deny access based on IP, for example, and there is no intrinsic support in HTTP or browsers, which leaves you with two possible hacks: correlate requests for graphics, etc, with recent page requests; and use cookies.
The first hack doesn't work, in particular because of caches. Your browser may still have the page cached, but not the graphic.
The second hack doesn't work because many people disable cookies.
I think the best analogy comes from print media. You can quote a small amount from elsewhere, as long as you credit the original source (quote by author in media). You can reference other material (see book, page). But including copyrighted work which is a substantial part of another publication (either in quantity or content) and especially when there is no explicit indication that it is not your own work, is infringement.
You're absolutely right. I was considering whether or not to raise the point about multiple NICs, but then for a fault tolerant system you should have them anyway from a redundancy point of view.
The question of necessity (in terms of bandwidth) comes down to the client-server design rather than the database design. The database server may provide lots of information lists to the client (say, a customer list, and then a query will return detailed customer information) which will require a huge amount of bandwidth if there are a lot of clients. OTOH the clients may be primarily interested in correlative queries, in which the database server is doing a lot of processing to come up with a relatively small answer.
I think the main issue was that the original poster seemed to make the mistake of thinking gigaBYTE ethernet, not gigaBIT, and implying that the networking would not be a bottleneck to the disks.
First, you need to consider that because of data locality, you are never going to reach the STR you are pondering. Queries would have to magically occur in such a way that the disk load was perfectly balanced between all drives. Your worst case STR is therefore 43Mb/sec, ASSUMING you benchmarked the STR on random access rather than sequential access.
Second, as many others have said, use RAID0+1 ; RAID5 has overheads that (can) involve other drives in the chain.
Third, your Gb ethernet is gigaBIT. That provides for a maximum throughput of 125Mbyte/sec on a switched network. To improve on this you could use multiple Gb NICs ... but they are on the PCI bus, along with the RAID adapters. This doesn't necessarily halve performance (it could in the worst case scenario), but the degradation depends on the size of the request/response versus the data that must be retrieved and processed.
Forth, you have a couple of more obvious software overheads. Issuing a read or write takes time. Software has to interpret the query, formulate the strategy to come up with a solution, and make read requests. Those requests are processed by file system handlers, which translate into raw disk operations. This means your file system and database software are adding a lot of overhead and latency that will reduce the STR.
Basically you are wanting a heck of a lot of memory, and a vast amount of processing power to keep up with the potential of the hard drives.
It would seem that the terminology being used is somewhat confusing. "Linking" appears to indicate a direct URL reference in (say) an IMG tag, rather than a "link to a page" (A tag).
Essentially there is no problem with providing a link to the original page, where the image will be displayed in context, but pulling the full image out of context is an issue.
From previous legal challanges and discussions, it would seem that "framing" is much less clearly defined. Providing a banner which indicates that you are supplying content as a proxy (or similar circumstance) appears to be okay, but having a site embed content from another site (say in another frame) where there is no indication that the content is not yours, would be considered framing.
This tends to happen most often when the site with the content has frames, and you have frames (in both cases, HTML frames), and you can link directly to one of their frames without the rest being displayed.
The Koeburg facility on the Cape west coast is still operational. A reactor glitch and some sort of stuff up at the national grid switch in the middle of the Cape was responsible for that massive power failure in Cape Town last year. That facility produces 3200MW, larger than the coal stations in the Transvaal.
The second reactor has always been experimental, and never produced power commercially. It was shut down some time ago. In light of it being 26 years old and having two safety "incidents" recently due to low maintenance budget, there are proposals to close Koeburg in the near future (2008-ish IIRC).
You're (not 'your') an idiot ;) Grade 12 Geography. First world nations include those you listed, EXCLUDING the USSR, plus most of Europe, Austalia, Japan and others. Second world is a category which was reversed for the USSR and communist nations! Third world included all underdeveloped nations. Incidently there are also "forth" and "fifth" world classifications, which served to break up the "third world" category more precisely.
It is an issue of some contention as to whether SA is "first" or "third" world. It is generally considered to be a duality - much of our infrastructure and cities is first world, but the problems of poverty and service delivery are typical of third world nations.
Let's see. In SA we have (1), (2) [at least at local/national government level, and for many people], (3), (4), (5), (6), and (8). (7) is debatable because while there is legal respect for individualily, many ethnic groups believe strongly in an "elder", even if they have the right not to. (9) depends on who you ask - the strongest split in SA is still along racial lines.
Oh dear, you must be an American. Try looking at http://www.polity.org.za/ which has information about SA, and links to most of the government web sites. We don't exactly need free hosting on Geocities; in fact we have already hosted an online debate on electronic commerce regulations (which is far more forward-looking than most developed nations).
Oh, by the by: [nucleartourist.com] (South Africa) ESKOM is the 5th largest utility in the world. They operate the 2 Koeburg reactors, each with a capacity of ~900 MWe. They do have a page listing their generating facilities with capacity.
ESKOM also developed and are prototyping pebble-based molecular reactors, which Germany and France gave up (citing as impractical) nearly two decades ago. These promise to provide cheap, clean and safe energy to anything up to a small city, and can be located where needed. They promise to be a solution to the energy problem in the third world.
South Africa is fairly unique amongst developing (esp. African) nations. We have an excellent infrastructure for transportation and communication in most parts of the country. While many people do not have their own telephone lines, there are ongoing projects to remedy this situation.
But far more interesting is the fact that these are a huge number of people living in ghetto-type conditions with no basic services, who are using the cellular networks to communicate. This goes to show that there is money and intent available for electronic communication.
There are several existing projects to get PCs into underdeveloped schools. In fact the hardware side of the projects is quite successful, but they are struggling because of the cost of software and the lack of teachers with computer experience. Linux is not suitable in such environments until it is easy to install and administer with little or no experience.
One of SA's biggest barriers to bringing "computing to the masses" is the commercial attitude: SA is extremely loyal to Microsoft, and to leading-edge technology. Technology more than a couple of years old becomes nearly impossible to get. Few wholesalers stock chips under a Celeron/Duron 800, or RAM chips less than 128Mb. They perceive that there is money to be made from companies, and not from supplying cheaper hardware to more "charatible" causes.
SA suffers from a "nothing but the best" syndrome, which affects development. It is generally unacceptable to provide second-class solutions as an interim measure while working on a long-term solution. This means that, for example, a project to get computers into schools will involve building a secure building for the computers (many poor schools are prefab or have degraded buildings), and the provision of networked multimedia computers.
Having said this, it is obviously not the way to go. There needs to be an attitude change and an acceptance of older technology, alternative technology or interim solutions.
Actually the availability of communications is not important in the use of computing in developing nations. Computers can be used "offline" as teaching aids, and this is probably where investment should be targetted. Education standards in SA are dropping, there is a massive adult illiteracy rate, and computing skills (required in many industries) are lacking.
An obvious and useful proposal would be to develop and mass produce cheap hardware which can run OpenSource software, and start developing (locally) teaching aids in all national languages (we have 11 of them :
Incidently ... the mining sector only accounted for 6% of GDP in 1999 (worldinformation.com), Tourism for 4% and agriculture for 4%. What makes SA an economic power in Africa is its NON-reliance on mineral resources.
I could be a little out of date (maybe even a lot ;) ), but last time I checked you could do a lot of calming of DoSing by implementing proper packet filtering on routers.
IIRC most DoSing relies on the kiddie hiding their source address (so that they can't be traced). So ensure that the router closest to the kiddie knows all the IPs it is allowed to accept, and rejects (and logs) all others.
This puts an onus on ISPs to handle the situation. Any ISP which doesn't react immediately to a DoSer from it or a downstream stands to lose (all of) its uplink(s).
Most port handling equipment can handle quite complex filtering on its own, knowing the IP allocated to a port and filtering all packets without that as its source. Port handlers typically forward to a router anyway, so its easy for an ISP to say "that interface talks to that rack, which can use IP range X to Y, so filter everything else". Immediately your script kiddie is limited to faking addresses of other users in the range.
This screws up a number of DDoS attacks I know of (where the reply to an unwitting host causes shit for the replier), and makes it a lot easier to trace the kiddie at least to within a limited number of possibilities.
If the ISP supplies a link to another ISP it must ensure it toes the line. Bulk links to corporate customers or anyone with a range of IPs (rather than just one) at the other end of the link can usually be handled like dial-ups: port handlers filter out bad source IPs.
Does anyone know of technical and/or political reasons why this can't work? If there are no technical problems then maybe an IETF policy committee needs to make it a standards issue.
The fact that you aren't prepared to stand up to your manager is the first sign of a problem. You have to make management understand that you are (I assume) a professional. Development or (hopefully) software engineering is your career, for which you are educated, and that in such areas management does NOT have the required knowledge to act.
In no other technical profession can management dictate HOW the job should be achieved. They can set budgets and deadlines, and assist in planning, but they do not have the liberty to force a domain expert to act in a certain way.
This needs to be made more clear to software managers. Software is difficult to write and to maintain. Even though most contracts seem watertight, there is an element of liability implicit in the sale of custom-developed software, which makes YOUR organisation responsible. And as the software engineer someone is going to shit on YOUR head when things go wrong ... not the manager's.
Have you even looked at extremeprogramming.org?
XP is divided into four major areas of activity: Planning, Designing, Coding, Testing. The project starts with requirements analysis and an architecture or framework for the entire system. Emphasis is placed on simplicity and preventing feature creep. Then it goes into an iterative development phase in which the emphasis is on rigerous unit testing and feedback, ensuring that code works, and problems are detected early.
The value proposition of XP is risk control: feedback provides a good idea of problem areas and allows for handling them when they arise, and iterative development ensures that feature creep and miscommunicated requirements cause limited damage.
You are correct that XP is not that new. It bears many similarities to the Rational Unified Process, but is in no way related to RAD. XP stresses the importance of an underlying architecture and extensible design, before coding is started.
Would you care to expand on what you mean by "REAL Software Engineering texts"? Most people seem to believe that scientifically provable methodoligies are the only option for software engineering ... how unfortunately that it was recently proved that it is impossible to reliably estimate software complexity, which is a core requirement for software engineering.
Or perhaps you have forgotten that software engineering, not other engineering disciplines, does not concern itself solely with technical aspects of the software, but business aspects as well: resources, deliverables and schedules.
XP is significant in being one of the least presumption of design methodologies. It does not require any knowledge, on the part of the programmer, of the business processes of the end user. Many software engineers think this is wrong, without realising that business process engineering is a sector-specific activity and an entire field of study; not something a software developer can pick up in a few weeks in order to do requirements analysis.
Cooper gives an example of a building architect interacting with the customer and the engineer to determine all of the building requirements before building starts. What he fails to take into account is that the building is a framework - as long as it has the right size, foundations and number of floors and elevator shafts, it is going to support a huge variety of functions.
Once the shell is complete, other teams move in to customize bits within the building. You can vary the number of elevators available within the limits; make them faster or slower, or only stop on certain floors. Each floor can be divided up with hardboard walls, plumbing and electricity get installed into ducts, aircon is added, carpetting, and finally furniture and fixtures. These don't need to be designed up front.
XP, unlike non-iterative methodologies, happily delays these details until later. RAD, by comparison, starts with the wall art and curtains, adds some furniture and walls, and then falls flat because it doesn't have a building.
There seems to be a general perception in the middle/upper class that poverty is the fault of the poor for not uplifting themselves. This is a good sign of a complete misunderstanding of the socioeconomic system.
Let's start with minimum wage. You're right: its a minumum. It has nothing to do with the cost of living, but with the cost of surviving. It is set according to the requirements of a statistically average poor household (2.5 kids, high density housing, 1 working parent), and should allow them to maintain basic human standards of living according to the International Declaration of Human Rights.
So why should a bunch of capatalists be interested in such bullshit? Why don't they just get skills and improve their lives?
Because you, working on your expensive computer in your suburban home, require unskilled labour. Because you aren't prepared to fix your own potholes, take your garbage to a landfill or recycling site, sweep the streets, mow the verges, or watch for cracked beer bottles on a production line and smash them so that you can enjoy a cold one at the pub.
And because capatalists put too much emphasis on skill, and undervalue basic services of this nature, the system can't work without intervention at a political level.
The paradox that arises is that you can train unskilled people, but that leaves a vacuum for unskilled labour and an abundance of low-skill labour. The economic of supply and demand kicks in, and you end up with situations that have been seen in Germany and the far east: production line workers (low/moderate skill) earning less than menial labourers (street sweepers, etc), because no-one with skill is prepared to do such an arbitrary job.
An ecnonomic system, like a political system, is a compromise between government and individuals. Some individuals want complete equity in distribution, some want complete anarchy. The compromise is the point at which restrictions are placed: with capatalism the point is close to anarchy.
This compromise is needed because in a pure capatalist society, those with money can dictate to those without. Even a highly skilled individual cannot earn a good salary if companies are not prepared to pay one. Competition and demand only work to a limited extent: if all companies recognise that they can get a resource cheaper, they will force such a response from the market.
Notice how consumers are generally unable to apply pressure to large companies, but the reverse is not true. Microsoft, Sony, and Universal come to mind. When dealing with necessary resources (like a job) as opposed to optional or luxury items, the laws of supply and demand largely go out of the window.
In other words, the job of a capatalist government is (amongst others) to ensure that there is an unlimited ability to grow money, but that must be balanced against the rights of individuals to earn money, and the cost and value of services that need to be provided to society. The prevention of collusion and the use of minimum wage are extremely effective in creating such a balance.
Democracy is not about listening to the rule of the majority. It is about accomodating the majority while protecting them and the rights of all minorities. Capatalism is inherently at odds with democracy, which is why most first world countries tend towards socialism (especially in Europe).
Hi. Just FYI, out performance testing results. We have three implementations of this server: NT IO-Completion ports, select() and multi-threaded.
Testing was done using n identical clients, all flooding synchronous requests. i.e. each client sits in a "send, wait for reply" loop. The bottleneck is network bandwidth - we get sub-optimum performance except on Gb ethernet.
The nature of our server is such that max. performance is reached at at 8-12 conenctions. The multi-threaded server has the best performance out to 20-25 connections. IO completion ports scales out to 500 connections, dropping only 3% in performance (compared to 12 conenctions). select() never tops the scales, but is consistently about 1% behind IO completion ports out to 120 connections, then drops back to 10% behind out to 250 connections, then drops off horribly.
I will readily admit, however, that our implementation using select() could be more efficient. Even so, in architectural benchmarks it doesn't fare well beyond about 400 connections in a server doing IPC/RPC type transactions.
Hmm. I'll try the polite answer, shall I? :)
First, I said Apache-style architecture, not Apache architecture. This means a pool of independant entities all of which block on a common kernel signal, and the first one to obtain the signal takes and processed the associated request synchronously with respect to itself.
Whether threads or processes are used is largely academic, and is not an architectural consideration (it is an implementation consideration). On most Unix systems threads are not first-class entities in the scheduling system, and cannot be considered for high performance applications. Win32 systems on the other hand support multithreading as well as multiprocessing natively, and Apache itself could be implemented as efficiently using threads as using processed (possibly more so, because win32 doesn't have copy-on-write process creation).
Java is perfectly capable of supporting several architectures other than thread-per-connection. Not to mention that Apache itself is a thread-per-connection (or process, if you wish to draw a distinction); in which threads/processes are reused, and a limitation is configured on maximum simultaneous threads/connections.
The most significant thing about the Apache architecture is that there is no controller process which listens on the server socket and assigns new connections to pooled processes. Instead, each process is a peer, and listens for new connections when it can. This enhances both performance and stability. This is what I was meaning when I referred to an "Apache-style architecture".
Java is able to scan in a non-blocking manner for new connections, or for data on a connection. As such it can implement pseudo-select() functionality. JDK1.4 in fact has the nio package which implements a Java equivalent of select().
Finally, in connection with your claims about performance, I said "average client-server application". You have quoted me an extremely contrived benchmark. Not only is the serving of 1 byte files unreasonable as an "average" application, but a web server is not an application server, but a file server.
Quote me a benchmark on a Java server versus a similarly-architeced C++ server in which there is some serving of static content, but primarily (say 70%?) involves server-side processing (even page generation would be reasonable), and I'll be more inclined to accept your view.