Monday, February 28, 2005


[Communications]IDA frees spectrum for mobile broadband

By Aloysius Choong, CNETAsia
Friday, February 25 2005 6:01 PM

update SINGAPORE--The Infocomm Development Authority of Singapore opened up the 2.3GHz and 2.5GHz bands on Friday, paving the way for new mobile broadband providers in the island-state.

The much-anticipated decision will see the national regulator dividing the spectrum into 25 lots, with most companies allowed to bid for up to the six lots that ensure islandwide coverage. IDA will, however, limit incumbents StarHub and SingTel to four lots each, in an attempt to encourage new market entrants.

As many as four new nationwide broadband operators may thus be confirmed in April, when interested companies submit their bids and IDA allocates the spectrum. This is expected to bring about several new wireless services to consumers, including ubiquitous high-speed Net access and voice over Internet telephony.

According to IDA's director-general for telecoms, Leong Keng Thai, the move was sparked by an increasing demand for broadband services.

"While Singapore has, to some extent, good broadband offerings today, we can still afford more competition in terms of new and more broadband infrastructure, technologies and operators," said Leong. "This will in turn translate into lower prices and more choices for consumers."

IDA hopes to satisfy all demand for the spectrum with its new release, added Leong, but if there are more offers than anticipated, an auction will be held with a minimum starting bid of S$1,000 (US$612) per lot.

The regulator will not impose requirements on carrier technology or provider interoperability. Unlike 3G licensees, mobile broadband providers can also opt to roll out services in a limited area rather than nationwide.

Depending on the technology deployed by operators, wireless services may eventually be accessible from either fixed points or mobile devices. But due to a commitment IDA has made to current 3G operators, broadband entrants will only be able to offer mobile services after January 2006.

When contacted by CNETAsia, industry players greeted the announcement with mixed responses. Internet service provider Pacific Internet welcomed the spectrum release and applauded the IDA's limitations on incumbents. According to a spokesperson, the company will study the invitation and plans to bid for the full allotment.

Mobile and broadband operator StarHub, on the other hand, questioned the regulator's timing.

"We think it is premature for IDA to auction these bands now as wireless standards are still evolving," said Chan Kin Hung, head of StarHub's Mobile Services. He added that the company was "disappointed" by IDA's decision to limit its allocation, saying that this could impact its ability to provide services.

Other 3G operators SingTel and M1 told CNETAsia they were evaluating the situation.

Many technologies have been touted for the emerging mobile broadband segment, including TDD (time division duplexing), offered by several vendors, and Flarion's Flash-OFDM. In Korea, operators are deploying the WiBro standard in the 2.3GHz band.

But with different technologies offering different capabilities and harnessing different frequencies, some carriers are waiting for a global standard to emerge. One such candidate is WiMax, based on IEEE's 802.16 standard, which many expect to be largely adopted in the 3.5GHz band.

According Leong, IDA may release the 3.5GHz spectrum in the future, a development that both StarHub and Pacific Internet are monitoring.

"3.5GHz is heavily used in Singapore for fixed satellite services," said Leong. "We can't take away that frequency overnight. But we are looking at it to see whether it's feasible to take part of the spectrum. If it's possible, we may allocate that."

Successful bidders for the 2.5GHz band will have to offer public wireless broadband services within 18 months, while those working on the 2.3GHz band will be given 36 months due to the limited amount of equipment, said Leong.

They will be given 10-year spectrum tenures, with annual fees of S$13,200 (US$8,084) per 2.3GHz lot and S$13,500 (US$8,268) per 2.5GHz lot.


[Enterprise : Management]Dealing with large-scale disasters

By Mike Talon, TechRepublic
Friday, February 25 2005 8:23 PM

In any column dealing with Business Continuity Planning (BCP) and Disaster Recovery (DR), there will no doubt come a time when the discussion must turn to large-scale disasters.

There has been a great deal of press and awareness of man-made disasters, and lately there has been a true surge in coverage of natural disasters with hurricane after hurricane slamming into multiple cities again and again. Both types of disasters can and do cause massive loss of systems, even entire locations, not to mention the loss of life involved in the wake of these events. How will your organization handle this type of disaster?

No organization can claim readiness for large-scale disasters without addressing the trinity of BCP: Human Resources, Facilities Management, and Information Technology. This trio must work in concert to properly overcome a disaster's impact, so you will not be able to do this alone as an IT professional. It would seem that even with all three groups working together, you will still have an overwhelming task ahead of you, but if you break the tasks down into component parts, you can manage the event and maintain your business systems.

The first order of business is to get good information flowing in. In the wake of a major disaster--natural or man-made--you will no doubt find a wealth of information that you will need to sift through to verify what is real, versus what is either imagined or simply exaggerated. Case in point: After the initial shock of the power failures in the northeast United States in August 2003, many people were absolutely convinced it was a terrorist attack, when in fact it was simply a large-scale technology failure across several systems. Finding out what happened and what resources you still have available is a vital first step in the process of dealing with a disaster.

Your next priority is to get good information flowing out. Make sure everyone who needs to be in the loop during the initial recovery process is available, or that substitutes are brought in. It may sound easy on the surface, but remember that physical and mobile phone service may be interrupted, e-mail systems will probably be offline, and other communication systems may be acting erratically. Find the systems that are still working and get the word out as soon as possible.

Hopefully, you have already determined your Recovery Time Objectives (RTO) for your various systems before the disaster struck. If not, there is very little you can do but try to bring everything back up as soon as you can. If you do have RTO numbers, start working with the shortest recovery times and bring those systems up in alternate locations first, and leave all the other systems for later--no matter how much people start yelling at you to bring them up sooner.

At this point, you must concentrate your staff on the most important systems first, regardless of the apparent urgency that already panicked staffers may express to you regarding other systems that everyone agreed were less important prior to the actual disaster. Keep in mind that this may mean finding alternate data-center space and acquiring new hardware if you haven't already planned for these eventualities. This is where Facilities Management comes in to make sure you have a location to set all this up.

Finally, after all the urgent issues have been addressed, you can then begin to bring up other data-systems as time and equipment will allow. If you're in a smaller shop, HR, Facilities, and IT may all be the same person, making your job somewhat easier and harder at the same time, but all three groups must be brought into the equation.

Dealing with a large-scale disaster is something that everyone would prefer not to have to deal with. Recent events have proven that it is--unfortunately--an eventuality that no organization can afford to ignore.


Embedding HSQLDB into your applications

Using a database for your application's permanent storage is a practical, standard decision.

But what do you do when your application is deployed on a machine that will not have access to your company's enterprise databases?

You take the database with you.

If you need a database on the go, then HSQLDB may be the solution for you.

HSQLDB is a compact, 100 percent Java, SQL standards-based, database engine. You can embed HSQLDB into your applications and control it programmatically, or you can run it as a stand-alone database as you would any other JDBC-compliant database.

It's useful when you need database access from a location with no access to your company's network; when you need an in-memory storage solution; or as a resource for unit testing your database components.

HSQLDB stands apart from many open source projects by providing extra features with the core product.

For instance, HSQLDB has a built-in Web server and comes with a servlet for accessing the database. The tiny database also supports triggers and indexes and allows you to call Java procedures directly from within your SQL statements.

Feature-for-feature and performance-wise, HSQLDB cannot compare with the standard commercial solutions like Oracle, Microsoft SQL Server, and Sybase.

But if you need an embedded database for your application, then HSQLDB might be the right answer for you.

David Petersheim is the Director of Application Development with Genscape, Inc. He designs and develops server-side applications to acquire and process real-time energy data.

Sunday, February 27, 2005


18人获颁汉语桥奖学金超过一半是学生 可到中国留学

logo 新闻:新加坡 2005-02-22

  超过一半是学生 可到中国留学

● 王慧容



























新电信即日起 推出3G通信服务

● 吴庆康




  新电流动(SingTel Mobile)总裁林泉宝说,采取这样的收费策略是因为消费者没有理由需要付出更多才能够享用3G通信服务。

林泉宝说,新电信确保用户从2G通信过渡到3G通信的过程通畅无阻,用户只需到新电信属下的商店购买新的3G手机,并换取3G用户识别卡(SIM Card)就行,每个月的服务费收取程序将没有改变。



  为了配合3G通信的开展,新电信也将免费提供3G通信的部分内容服务,包括推介阶段的免费影像串流(video streaming)。









  3G通信服务包括视像电话(video call)、影像实时串流(video streaming)、3G数据传输、接收新闻快讯,以及进行网上活动如下载游戏和录像等。

3G是3rd Generation的简称,指的是第三代流动电信科技(Third Generation Mobile Telephone Technology)。


















Thursday, February 24, 2005


[Enterprise : Management]DR tip: separate servers from applications

DR tip: separate servers from applications
By Mike Talon, TechRepublic
Tuesday, February 8 2005 10:44 AM

Many times, when discussing Disaster Recovery (DR), engineers tend to lump together both servers and the applications that sit on those servers.

The mistake made in these situations is that most disaster scenarios require only a limited number of users or systems be supported by an application, which in turn will require fewer server resources than the frontline version of the app. I must admit I've fallen into this habit myself on occasion, and very few qualified engineers are immune.

The main issue with this line of thinking is that--in many cases--doing so will limit your ability to failover applications, and this will often force you to allocate a larger budget number to a disaster recovery project than is necessary. There are two common repercussions that can come about as a result of not thinking about applications separately from servers:

* You may allocate an entire failover server to an application that could have shared space with another app on a DR server.
* You could also allocate hardware that is powerful enough to handle normal operations to the DR center, when only a small sub-set of the total processing power is needed for failover scenarios.

Single-engine applications
Many applications must be allocated to their own servers in order to operate at top capacity or to operate at all.

Common examples are data systems that are single-engine programs, where only one copy of the software can conceivably run at any given time. In these cases, you will no doubt find that you do have to protect and failover these applications and servers as a unit. However, you may not need to allocate nearly the same budget amount to the backup data-systems as to those in production.

Unless all operations are going to failover in the event of an emergency, you will have far fewer users--both internal and external--after a disaster has occurred. Because of this, your data-systems will almost definitely be able to operate with much lower levels of hardware in terms of CPU, RAM and other critical and often expensive components. In many cases, you can even use equipment made available by a hardware refresh to be repurposed as disaster recovery equipment.

In the majority of cases, applications have no problem sharing servers with other applications. A large number of applications are beginning to be built with this idea in mind, allowing for multi-instancing or the ability to limit the amount of system resources they consume. This allows you to either failover multiple applications to a single physical machine, or deploy multiple redundant instances of the same application, depending on the application in question.

Just make certain to properly size the DR servers so they can handle the load of multiple applications, keeping in mind that there will be fewer users on each app.

As server virtualization tools become more mature and readily available, you will be further empowered to create customized combinations of failover systems that take into account the distinction between applications and their parent servers.

No matter what combinations of solutions you decide on, taking this into account during disaster recovery planning will ensure that you have the most effective combination of budget and protection.


[Enterprise : Management]Create an incident response policy

By Mike Mullins, TechRepublic
Monday, February 21 2005 5:16 PM

Does your organization have an incident response policy (IRP)? You may not think you need one. You've locked down your organization's network, and your disaster recovery plan effectively details how to respond to a security incident--so you feel relatively secure.

But even the most secure networks need an IRP. Regardless of the severity of the incident, it's essential that your company has a policy in place that outlines steps to take during potentially disastrous times.

Every organization should include an IRP as part of its overall business continuity plan (BCP). Knowing how to minimize security vulnerabilities and respond to security incidents in a well-organized and thorough manner should be a critical component of any company's BCP.

A security incident is any adverse event or threat that affects your organization's information systems or network. Incidents can include unauthorized access, malicious code (such as viruses), network probes, and denial-of-service attacks.

An effective IRP should address eight key areas. Let's take a closer look.

1. Demonstrate management support

First and foremost, your policy should clearly outline management's support of the policy. A member of senior management--or anyone with the same authority to address the included provisions--should sign the policy. These provisions might include any financial resources, personnel, equipment, and training dedicated to implementing the policy as well as internal consequences of violation.

2. Decide an organizational approach

There are two common methods of dealing with an incident: Contain, clean, and deny, or monitor and record. The method your organization chooses should depend on whether the goal is to seek prosecution and/or compensation or to quickly restore services.

3. Determine outside notification procedures

Allowing your network to participate in a distributed attack and remaining silent is a legal landmine waiting to explode. In our collaborative world, it's important to determine procedures for notifying third parties if you're involved in a distributed event. Decide whom you'll inform as well as when and how.

4. Discuss remote connections

Your policy must address remote connections. This should encompass all remote employees or contractors, and it needs to outline your rights to disconnect and remove access during a security incident.

5. Define partner agreements

Describe downstream and upstream agreements with your service providers and customers that define your right to monitor and disconnect the network as required.

6. Develop an incident team

Identify by position (not name) the members of the team that will enforce the policy, and describe their roles, responsibilities, and functions. The team should encompass a variety of skills and areas of expertise, including security, administrators, human resources, and legal.

7. Design an internal communications plan

Develop an internal communications plan that identifies who you will notify and how you will contact them. In addition, decide on the person who's responsible for initiating this contact.

8. Demand a follow-up report

Define a method for reporting and historically archiving the incident. Use that information to tune your operations to prevent a similar incident from reoccurring.

Every network is unique, and the type of business your organization conducts on the Internet will influence the level of your response to a security incident. As your network changes, make sure you adjust your IRP accordingly and address newly discovered vulnerabilities as they occur.

Final thoughts
If your organization has no established, coherent plan of action, it can easily make the wrong decisions both during and after a security incident. An IRP policy can't solve your problems, but it can offer a cool-headed method for dealing with a hot issue.

For more in-depth information on incident response, check out SANS' Information Security Reading Room , which offers a wealth of available information that can help you create a comprehensive incident response policy.

Mike Mullins has served as a database administrator and assistant network administrator for the U.S. Secret Service. He is a Network Security Administrator for the Defense Information Systems Agency.

Wednesday, February 23, 2005


GNU resources


Disable Internet access on a Windows PC

By Jason Hiner MCSE, CCNA, TechRepublic
Friday, December 17 2004 3:52 PM

TechRepublic member gryandmary used the Technical Q&A to pose the following question: "Can I target a client PC and disable Internet surfing, through a Windows 2000 Server with DSL connectivity, while still maintaining communication with the server? We are using Microsoft Windows XP Pro on the client."

Here was the response from TechRepublic member zaferus: "There are two ways you can disable Web browsing from a Windows system:

1. Go to Internet Options in the Control Panel. Go to the Connections tab and click LAN settings. Uncheck "Automatically detect settings" and then check "Use proxy server" and put settings in for a proxy server that doesn't exist. This will time out the Web browser each time a user tries to pull up an Internet site. Unfortunately, a savvy user could go into the settings and fix this.
2. Alternatively, you can set the Internet router to deny all port 80 traffic to the WAN from the IP address of the client PC you want to block. This is something that the user is less likely to figure out, and it will effectively block that one PC from Web access, while still allowing all over LAN users full access to the Internet."

TechRepublic member brian added another option:

"Go to:

* TCP/IP Properties
* Advanced
* Options
* TCP/IP filtering Properties
* Select Enable TCP/IP filtering (All adapters)
* Select Permit Only for all three selections (TCP, UDP, IP)
* Add only the allowed ports that are needed (leaving out port 80 for Web browser traffic)
* Click OK multiple times to close out the windows

These settings could also be set in a Group Policy GPO so that the user can't change them. You would make a special group just for this user."


[KM]What is Business Transaction Performance Benchmark?

Total business Operations per Second (TOPS)
$/TOP is the price of the System Under Test (including hardware, software, and support) divided by the TOPS.

Monday, February 21, 2005


The many uses of netcat

The many uses of netcat

Often referred to as the "Swiss Army Knife of networking," netcat is a tool that administrators can use to read and write TCP or UDP data across the network. In addition, it's extremely useful for network debugging and testing.

Netcat offers several interesting uses. For example, you can make it listen to a particular port and run a program. To do so, use the following:

$ netcat -v -l -p 10111 -e "/bin/cat /etc/motd"

This tells netcat to listen to port 10111. When there's a connection, it tells netcat to execute "/bin/cat /etc/motd," which essentially displays the contents of /etc/motd and exits.

You can also set up netcat on a machine to listen for incoming connections and run it on a remote machine to connect to the local machine and serve up a bash shell. For example, on a local machine with an IP address of, you would use the following:

$ netcat -v -l -p 10111

On the remote machine, you would use:

$ netcat 10111 -e /bin/bash

This tells the netcat instance on the remote machine to connect to the netcat instance listening on and serve up a bash shell from the remote machine, which will then be available on the local machine. Using the netcat instance on, you can execute shell commands on the remote host.

To perform some Web debugging, you could use something like the following:

$ netcat 80

Then, enter typical HTTP commands to get the unaltered output (e.g., "GET / HTTP 1.0").

As you can see, netcat is both an extremely versatile and very powerful utility. You can download this useful tool, based on the original netcat program, from the GNU Netcat Project Web site.

This page is powered by Blogger. Isn't yours?