I didn’t find a talking clock package, sadly. But I found several alternative alarm clocks (Alarm Clock, saytime, Amarok/Rhythmbox plugin, etc.) which can play out a custom sound. Some people in ubuntuforums.org recommended using espeak (voice sounded too mechanical) or festival (large install) to read out the time, but there were always some problems. I was too lazy to program myself, so I was looking for a quick install, but searching for one is eating up my time more than if I just did the scripting myself. So I decided to make use of cron instead, and some bash scripting to get the job done. Now, I have a “lady” reminding me of the time every hour!

So, here’s what you need to do:
Disclaimer: Scripts done for my personal use. Use at your own risk. :P

1. Download the voice files. I found mine (I used AT&T Audrey) from Steve’s Talking Clock.
2. Concatenate the files to form your alarms. I used sox to concatenate its.wav {time}.wav and {am/pm}.wav. So mine says “It’s 9PM.” You can use and modify the generate_voice.sh if you want a different alarm format. The files will be stored in .clockvoices by default, if not specified during the call.
   
   #!/bin/bash

   voicepath=${HOME}/.clockvoice
   command="sox its.wav"

   if [ $# -ne 0 ]; then
     if [ $1="--help" ]; then
       echo "Usage: generate_voice.sh "
       echo "Make sure to run this while in the directory of voice files."
       exit
     else
       voicepath=$1
     fi
   fi

   echo Saving in ${voicepath}...

   for j in 0 1; do
     for i in `seq 1 12`; do
       period="am"
       if [ $j -eq 1 ]; then
         period="pm"
       fi

       fname=$((i%12+j*12))
       if [ $fname -lt 10 ]; then
         fname=0$fname
       fi
       `$command $i.wav $period.wav ${voicepath}/${fname}00.wav`
     done
   done

3. Write the bash script to play out the proper file according to the time. See readtime.sh. This will be the script that cron will execute hourly.
   
   #!/bin/bash
   # readtime.sh

   voicepath=${HOME}/.clockvoice
   hour=`date +%H`

   if [ $# -ne 0 ]; then
     voicepath=$1
   fi

   play ${voicepath}/${hour}00.wav

4. Set your cron’s schedule by typing crontab -e Add an entry like so: 0 * * * * {absolute_location_of_readtime.sh}

That’s about it! Enjoy! :D

The paper discusses the design considerations of the TCP/IP protocol suite widely used nowadays for internetworking.

Addressing/Routing
It used to be that different networks had different addressing schemes, which prior to internetworking, was okay since it is internal to each network. Internetworking, however, would require that all networks would be able to understand each other, so a common addressing scheme in TCP/IP was pushed for implementation — having all addressing schemes implemented on devices is unfavorable because these are unbounded.

The hosts are responsible for attaching the source and destination addresses, while routing is done by the network switches and gateways/routers. Much like our (snail) mailing services, the correspondents are responsible for their letters/packages, and indicating who sent it (return address) and to whom it is for (destination). The mailing service is only concerned with the delivery and does not (should not!) open or modify the letters/packages; it just forwards the letters/packages to the appropriate office until the final local post office can deliver it to the supposed recipient.

The packets also contain other information such as the byte count, sequence number and flags. Going back to our letter/package analogy, these can be likened to miscellaneous information such as the package dimensions and weight, as well as flags like “urgent” or “priority”.

Fragmentation and Reassembly
The acceptable packet sizes may vary for each network, so the gateway may split the packets into smaller fragments to let it through the next network. Reassembly is the done at the hosts, because if implemented at the gateways could potentially lead to buffering problems and deadlocks since all fragments of a packet will have to be collected in the gateways for reassembly. What happens if a fragment goes missing, and what if the resulting reassembled packets are too large to fit the router’s buffer? Aside from these problems, reassembly at the routers cause delay due to processing and is a wasted effort, since packets will have to be re-fragmented at the next router anyway.

The maximum packet size is not specified (1) to preserve the individual network’s internal parameters; (2) to make provisions for future developments which might support larger packet sizes, and (3) to allow expansion of packets when new information is attached or incorporated during transit.

Reliability/Sequenced Delivery
While multiplexed packets may be addressed to the same destination, the destination TCP should be able to identify which packets are for the specific processes. It does this by incorporating a process header to indicate the source and destination ports of the communicating processes. Each segment is encapsulated in a packet with its own checksum and byte count, and a sequence number unique to the communicating processes. These information, together with the flags in the packet, helps the destination TCP in determining the sequence of the fragments to reassemble the split message.

As the previous sentence suggests, TCP/IP puts the responsibility of ensuring ordered delivery and reassembly on the hosts. The network is only used for delivery, and even then, delivery is only best-effort and not 100% guaranteed. It is up to the hosts to verify the correct arrival of the messages and to request a resend should there be problems encountered. Acknowledgement and timeout mechanisms are applied to ensure successful delivery.

Security
Authentication is the responsibility of the host processes. The network lacks the capacity to intelligently verify the legitimacy or authenticity of the messages, since it does not have sufficient knowledge on the nature of the communication between the host processes. It is a different matter, however, when the encryption of entire network is desired to protect itself from misbehaving users.

Real-time Guarantees
The Internet is “best-effort” and does not assure 100% reliability. Application requirements for services vary: some applications, such as speech, require low latency and can tolerate packet loss, whereas others have can tolerate delays as long as the packets are delivered in-order.

The Internet has exponentially grown from its inception up to now, roughly four decades later, with little modification. A time-tested design, it has been the vehicle of varying information, no matter the kind of transmission medium the pathway is. The TCP/IP suite would not have developed and remained to be the standard until now if not for the designer’s objectives of following an ordered set of goals.

First and foremost, the goal was to interconnect the then-existing packet-switched ARPA and ARPANET networks. This determined the structure of the Internet: a packet-switched communications facility connected using gateways. The next goal was survivability — two communicating hosts should be able to converse despite network disruption, as long as there is any path between them. The Internet, after all, is a communications facility funded by the DARPA and should serve its purpose even during wartime. This required that state information be stored at the end hosts in what is called “fate-sharing” model — state information, if stored in the gateways, is useless anyway if any of the communicating hosts lost its connection (see end-to-end argument). The designers also realized that different services are required, which cannot be supported by a single protocol, so TCP/IP was split into two layers. The rest of the goals were given less priority but achieved to a certain degree: distributed management, cost-effectiveness, easy host attachment, and accountability.

The widespread use of the Internet past its military origins is currently challenging its design limits. As noted in the paper, a different protocol would have resulted had the priorities been different. The needs at the time of TCP/IP’s inception are quite different from the current uses demanded of it. Today, there are so many applications for the Internet, from web browsing, e-commerce, multimedia streaming, etc. and each of these applications have different requirements in terms of service. Aside from the applications, the transmission media are also changing, with wired and wireless connections available. This means more possible environments and conditions on which these facilities can be deployed. The fast pace of technology has also given birth to many other devices that can connect to the Internet. All these will have to be accommodated and so the Internet, in its evolution, will have to remain flexible and extensible to support future developments.

The latter goals which did not receive as much attention as the first three goals are now requiring attention, especially now that the use of the Internet has been passed down from the military to commercial and entertainment purposes. Security is now a big issue — back then, the pioneers had the same objectives and the connected nodes can be trusted; the same can no longer be said today, with all the cyberattacks and malicious users in the Internet. Accountability is also more important now, as businesses and consumers would like to know how resources are being used and whether they are used fairly.

Still, I believe that the current Internet design need not be scrapped or overhauled from ground up; network research can focus on the other individual layers or study cross-layer approaches.

The report discusses the current trends in cybersecurity to help the Congress create policies in preparation for the possibilities of cyberattacks against critical infrastructure and to assign which bodies should respond to threats in national cybersecurity. The report paid particular attention to the link between terrorism and cybercriminals, and the attractiveness to attacks, as well as vulnerabilities, of the US infrastructure system.

Cyberattacks can be classified under three labels: cybercrime, cyberterrorism, or cyberwarfare. Investigating bodies have difficulty putting a label on cyberattacks due to the fact that it is hard to accurately and quickly determine the identity, intent and political motivations of the attackers as methods and tools for infecting computers are rapidly evolving and becoming more sophisticated.

Different trends in cybercrime methods were also discussed, including the use of botnets, malicious codes from websites, identity theft, and cyber espionage. Particular attention is given to the possibility of terrorist groups hiring the services and technical skills of cybercriminals for raising funds for terrorist activities.

Some notes:

1. Mindset: not enough priority for cybersecurity. Our dependence on computer systems is continuously growing, yet it doesn’t seem like we are giving enough importance to security, thinking that they could not inflict physical damage. We conveniently forget the fact that many control systems (power grid, floodgates, road systems, aircraft systems, communication systems, etc. — some of which are possibly interdependent) could be remotely administered through the internet and could wreak havoc when controlled by malicious groups or individuals. Just like what the late Ernie Baron used to say, “Knowledge is power” — theft of highly confidential information and other criminal activities could endanger lives. Old people are probably traditional in this sense.
2. Cybercrimes are “cooler” and more profitable. Young people, in particular, are vulnerable to performing cybercrimes, as they are tempted with the thrill (of doing something without getting caught), and the need to establish a reputation among peers by showing off their technical expertise. Some professionals are exploited through deception and other means, or lured by the lucrative pay. This influx of talents and clients support the rapid technological advancement and financial growth of this underground industry. There are probably more bad guys than good guys. :(
3. More focus on functionality in software development. Software companies usually spend development time on developing functionalities, with security probably as an afterthought. Security should be given as much priority as functionality — no one wants to use a software that has backdoors or broadcasts private information behind his/her back. However, consumers are probably not demanding security enough. (For example, some consumers buy cars for the sole purpose of traveling, with little care about how it guards their personal safety or whether it passed crash tests.)
4. User consciousness. Many are uninformed that when their computers are compromised, they become unsuspecting accomplices whose computers can be used as tools for enacting crimes (as in botnets). The importance of computer security should be impressed on everyone — students, professionals, home or mobile users, etc. In the same way that we learn about safety precautions and how to properly use the products we purchase (for example, how to make sure your gas range doesn’t cause fire), users should be taught to be responsible for their machines.
5. The open and distributed nature of the internet. The open nature of the internet which has spurred the explosion of IT developments over the years is the very same property which makes these illegal activities possible and very hard to trace. The distributed nature of the internet which makes it resilient and the anonymity it provides is a double-edged sword.

In a way, this battle between the good guys and the bad guys is advantageous to advancing technology and could be counted as part of human progress — which means, it will keep on going and going. All this discussion is making me think of the Dark Knight: It’s always tougher for the good guys; the bad guys take in hostages (and sometimes, coerce them to do bad things) which complicates the mission. Currently, it seems like the good guys are getting overwhelmed, and just playing keep-up.

In the same way that the Internet is a huge network of distributed administrative domains, responsibility should also be distributed. Cybersecurity should not be a concern of only the military or government; the software companies, electronics industry, academe, and consumers should also bear their weight in maintaining a clean virtual environment.

The objective of any communication system is to transfer a message from the origin to the destination correctly, promptly, and efficiently (ideally). However, as in all man-made systems, perfection is impossible — errors arise and compromises are made and a certain property (correctness, speed of delivery, cost, etc.) is prioritized depending on the application. In a layered architecture, all the layers will have their own imperfections, and where to implement and what the solution will be depends on how drastic and frequent the errors are.

The end-to-end (E2E) argument is a guideline in system design to relegate implementing functions to the endpoints (or highest level) if low-level knowledge is insufficient to successfully implement it. Saltzer et al. cites situations when an E2E approach is suitable, and when it is not. Examples of when the E2E argument applies are:

1. When the communication system is acceptably reliable (for all applications using it), and there are errors outside the communication system (and/or within the endpoints) that can only be checked by the endpoints;
2. When the communication system is shared, and other applications which do not require the function are penalized (larger payload/reduced bandwidth, for example);
3. Or simply when the endpoints can implement the function better.

In the “Careful File Transfer” example, the E2E approach is appropriate because there are errors that occur in the higher layers aside from those in the communication system, and so the endpoints will have to do their own checks anyway — efforts to ensure 100% reliability of the communication system would be a waste since it still won’t guarantee error-free messages. This is not to say that one should not exert effort to improve the communication system’s reliability, but rather, ensure that the communication system is sufficiently reliable for the applications using it, so that the cost of making it so is justified. The E2E argument also reminds designers to consider the effects to all applications using the shared communication system when implementing certain features as low-level functions, because they become imposed.

The IP layer in the TCP/IP model makes use of the end-to-end approach, and by implementing just the necessary functions and stripping off other features, the designers were able to make it flexible and extensible. Looking at how big the Internet has become, would make us appreciate this minimalist approach. The open-ended design now enables the Internet to be used in transmitting different kinds of data — text, voice, multimedia, etc. The TCP/IP suite’s design has served us well over the years, but research in the field is not stagnant because as more and more potential uses for it are unveiled, obstacles also appear. For example, what happens in an overly congested area where wireless LAN is the only option?

It is tempting for designers to create all the functions an application could possibly need, but this usually results in a bloated system that is slow and inefficient. An analogy that immediately came to my mind is some operating systems — consider Microsoft Windows. It used to be that the web browser Internet Explorer could not be uninstalled without causing many of the system applications to malfunction. I don’t like to use Internet Explorer as my web browser, but it is an imposed feature — installing other browsers like Mozilla Firefox or Opera does the web browsing function better, but the footprint of IE remains as I could not delete it from my hard drive. In this analogy, MS Windows is the shared communication system, the web browser is the function which could have been left to a higher layer (the user), IE is the imposed feature, Mozilla Firefox or Opera is the reimplementation, and the hard drive space is the cost. Another example that comes to mind is barebone computers.

E2E is applicable in many instances, but not always. The Internet is the way it is, because it was what was needed at that time — it developed from a set of goals; with some goals more prioritized than the rest. The designer needs a thorough understanding of the goals and requirements, and choose which approach is most appropriate. The mark could be anywhere between the spectrum; the designer’s objective is to find that sweet spot.

In his lecture, Thompson basically asked whether there is a software which can be fully trusted. One would usually be quick to answer that one cannot trust a software is free of malicious code, unless he/she wrote the source code himself/herself. But thinking deeper, one would be able to look at the bigger picture, and notice that the source code is not sufficient on its own to create the binary, because it needs a compiler. So then the question goes down to the trustworthiness of the compiler, recursively until the lowest layer of the software architecture, and even further down to the hardware. Essentially, if we would follow the condition that the only software we can trust is our own, then any software we use, as well as the underlying software and hardware platform it runs on, should be something we did ourselves. Which, I couldn’t resist adding, is just insane.

So, any software, even the one you write, cannot be fully trusted, because it depends on other tools that you didn’t write yourself. But it can be trusted to some degree, more so than you trust other programs you did not write yourself. You might believe a code you wrote is more trustworthy than someone else’s, inherently because you wouldn’t intentionally harm your own system, but later you might find out that it is less secure because of a bug you failed to see. Trust on a software, as my previous sentence illustrates, is more based on trust on the author/s. This extends to the tools. Equally important to a reviewed source code of the tools used is whether the authors are known to implement good methodology and have good reputation. This line of questioning extends further down then adds up until one arrives at a decision whether Software A is likely to be more dependable than Software B.

Reputation can be built by tests and certifications. For example, there are tests and certifications of processes and devices on compliance/conformity to standards specified by trusted bodies like ISO, IEEE, etc. Certification, the way I see it, becomes some sort of “association” to these reputable bodies, as though the trustworthiness “rubbed onto” the brand or product. This could lead to associations or alliances of companies with products that are certified. In wireless LAN, for example, there is the Wi-Fi Alliance, with member companies that commit to interoperability among their products. The same is true for software. For one, there is the Trusted Computing Group, which promotes Trusted Computing technology. But does this imply software developed by member companies of the Trusted Computing Group are fool-proof and can be completely trusted?

Apparently not. As Diomidis Spinellis pointed out in his paper “Reflections on Trusting Trust Revisited” with Xbox as a case in point. Reputation worked for the other bodies I mentioned, but not for TCG, at least for me. The difference probably lies in the fact that usually, certifications are done to guarantee that a product has met a certain functionality. Security is a far, far more complex and completely different property. The way I see it, perfect software security is an impossible dream, so a fully-trustworthy software will never exist, simply because there is always somebody smarter than you (if you are the designer) out there. Still, like I said, there are degrees of trustworthiness — Software A may be a tougher nut to crack than Software B — but to be fully certain that a software is impenetrable? Nah.

Kuya Noel, you ass. You didn’t even tell me!!! Ayhechu!

Anyways, if you’re a SkyDSL subscriber, you need to activate the SOD (which doubles your subscribed speed from 10pm to 10am) by calling the Bayantel Customer Service at (632) 412 12 12. Or if you don’t like calling for technical assistance (unlike me), just append “@sod” to your username account and your speed should double at the mentioned hours. Enjoy!

After days of searching for a demonoid invitation and repeatedly checking back at Demonoid.com, I was finally able to register. I’m really, really excited right now, waiting for the activation email to appear in my inbox.

My excitement is slowly turning into dread.. I mean, it’s been a few minutes and it hasn’t arrive. Come on… *sweats*

Anyway, just to inform the other guys, registration is currently open for those looking for entry. If it closes before you learned of it, well, I guess I should just say that keep on checking back. I learned from Yahoo!7 Answers that registration opens once every two weeks (though I’m not entirely sure if it’s true), but heck, I got one when I checked right after reading that. So, check frequently!

Update: I’m still waiting (in vain as it seems) for that activation email.. Just how long does it take to arrive? Anybody?

Update 2: It’s been a day and it hasn’t arrived. I’m giving up. I’ll just try signing up again when it reopens. I don’t know what the problem is — if it is with GMail or with Demonoid itself. I wish Demonoid has a way of resending the activation email. As it is, I couldn’t have the confirmation resent, nor can I ask for a new password. I knew I shouldn’t have hesitated to sign up again when the mail didn’t arrive. But my conscience wouldn’t let me! I keep thinking of the unfortunate guy whose slot I will be stealing.. *sigh*

Update 3: The confirmation email still didn’t arrive, but I was able to login now. It seems they automatically activated the accounts created during their last opening. Yatta!

Update 4: This post has been getting a lot of hits (Demonoid sure is a big keyword), and it disappoints me. It feels like I’m leeching off of Demonoid’s name. Plus the post has absolutely nothing helpful in it. So to change that, here are tips.

1. Make Demonoid your homepage. So that everytime you go online and fire up your browser, it automatically goes to the page and you’ll see if registration has reopened.
2. Be more specific. When you find some blog/forum where you can ask for an invitation, be as specific as possible in what you need to download. Invitations are limited, so members are picky with the recipients of their codes. It would help you get an invitation from someone if you can provide a good reason why that someone should give you an invitation. It’s also good to promise and prove you’re not simply an ungrateful leecher.
3. Be patient. This is the most important out of everything that’s been said, actually.

Also, be informed that invitations don’t always work; sometimes the site disallows new sign-ups despite having an invitation code. If that’s the case, try the code again some other time. Once you get in, show your appreciation: don’t just leech; do share and seed!