A couple of months ago I was at LinuxTag in Berlin with the friends from VIdeoLAN and we shared a booth with the XBMC project. It was interesting to see the newest version of XBMC running, and I decided that it was time for me to get a new XBMC box — last time I used XBMC was on and while it was not strictly disappointing it was not terrific either after a while. At any rate, we spoke about what options are available nowadays to make a good XBMC set up, and while the RaspberryPi is all the rage nowadays, my with the platform made it a no-go. It also requires you to find a place where to store your data (the USB support on the Pi is for many things) and you most likely will have to re-encode animes to the Right Format™ so that the RPi VideoCore can properly decode them: anything that can't be hardware-accelerated will not play on such a limited hardware. The alternative has been the Intel NUC (Next Unit of Computing), which Intel sells in pre-configured 'barebone' kits, some of which include wifi antennas, 2.5' disk bays, and a CIR (Consumer Infrared Receiver) that allows you to use a remote such as to control the unit. I decided to look into the options and I settled on the which has a Core i5 CPU, space for both a wireless card (I got the which is dual-radio and supports the new 11ac protocol, even though my router is not 11ac yet), and a mSATA SSD (I got a ), as well the 2.5' bay that allows me to use a good old spinning-rust harddrive to store the bulk of the data. Motionvfx bundle september 2017 for mac.
Be careful and don't repeat my mistake! I originally ordered a very cool but while it is a 2.5' HDD, it does not fit properly in the provided cradle; the same problem used to happen with the first series of 1TB HDDs on PlayStation 3s. I decided to keep the HDD and bring it with me to Ireland, as I don't otherwise have a 2TB HDD, instead I opted for a HGST 1.5TB HDD (no link for this one as I bought it at Fry's the same day I picked up the rest, if nothing else because I had no will to wait, and also because I forgot I needed a keyboard). While I could have just put on the device, I decided instead to install my trusted Gentoo — a Core i5 with 16GB of RAM and a good SSD is well in its ability to run it. And since I was finally setting something up that needs (for myself) to turn on very quickly, I decided to give systemd a go (especially as Robbins is now considered a co-maintainer for OpenRC which drains all my will to keep using it). The effect has been stunning, but there are a few issues that needs to be ironed out; for instance, as far as I can tell, there is no unit for rngd which means that both my laptop (now converted to systemd) and the device have no entropy, even though they both have the rdrand instruction; I'll try to fix this lack myself.
Another huge problem for me has been getting the audio to work; while I've been told by the XBMC people that the NUC are perfectly well supported, I couldn't for the sake of me get the audio to work for days. At the end it was Alexander Patrakov who pointed out to inteliommu=on,igfxoff as a kernel option to get it to work ( still unfixed). So if you have no HDMI output on your NUC, that's what you have to do! Speaking about XBMC and Gentoo, the latest version as of last week (which was not the latest upstream version, as a new one got released exactly while I was installing the box), seem to force you to install FFmpeg over libav – I honestly felt a bit sorry for the developers of XBMC at LinuxTag while they were trying to tell me how the multi-threaded h264 decoder from FFmpeg is great Anton, who wrote it, is a libav developer! – but even after you do that, it seems like it does not link it in, preferring a bundled copy of it instead. Which also doesn't seem to build support for multithread (uh?).
This is something that I'll have to look into once I'm back in Dublin. Other than that, there isn't much to say; the one remaining big issue is to figure out how to properly have XBMC start up at boot without nasty autologin hacks on systemd. And of course finding a better way than using a transmission user to start the Transmission daemon, or at least find a better way to share the downloads with XBMC itself. Probably separating the XBMC and Transmission users is a good idea. Expect more posts on what's going on with my XBMC box in the future, and take this one as a reference about the NUC audio issue.
Friday the project had its monthly online meeting to talk about the progress within the various tools, responsibilities and subprojects. On the toolchain part, Zorry mentioned that GCC 4.9 and 4.8.3 will have SSP enabled by default. The hardened profiles will still have a different SSP setting than the default (so yes, there will still be differences between the two) but this will help in securing the Gentoo default installations. Zorry is also working on upstreaming the PIE patches for GCC 4.10. Next to the regular toolchain, blueness also mentioned his intentions to launch a subproject which will focus on the musl C library (rather than glibc or uclibc) and hardening. On the kernel side, two recent kernel vulnerabilities in the vanilla kernel Linux (pty race and privilege escalation through futex code) painted the discussions on IRC recently. Some versions of the hardened kernels are still available in the tree, but the more recent (non-vulnerable) kernels have proven not to be as stable as we’d hoped.
The pty race vulnerability is possibly not applicable to hardened kernels thanks to grSecurity, due to its protection to access the kernel symbols. The latest kernels should not be used with KSTACKOVERFLOW on production systems though; there are some issues reported with virtio network interface support (on the guests) and ZFS. Also, on the Pax support, the install-xattr saga continues. The new wrapper that blueness worked in dismissed some code to keep the PWD so the $S directory knowledge was “lost”. This is now fixed. All that is left is to have the wrapper included and stabilized.
On SELinux side, it was the usual set of progress. Policy stabilization and user land application and library stabilization. The latter is waiting a bit because of the multilib support that’s now being integrated in the ebuilds as well (and thus has a larger set of dependencies to go through) but no show-stoppers there. Also, the on the wiki was briefly mentioned. Also, the has been so it is no longer applicable to us. On the hardened profiles, we had a nice discussion on enabling capabilities support (and move towards capabilities instead of setuid binaries), which klondike will try to tackle during the summer holidays. As I didn’t take notes during the meeting, this post might miss a few (and I forgot to enable logging as well) but as Zorry sends out the meeting logs anyway later, you can read up there;-).
We've made a few small updates to perl-cleaner that should get you around subslot issues much better in the future. If you are planning to do any major Perl update on your Gentoo box in the near future, please as a first step update to =app-admin/perl-cleaner-2.14, which is currently in arch but in my opinion a good stabilization candidate.
This will hopefully give you a much better upgrade of your Perl modules. Of course any feedback is appreciated, and if you encounter problems, please! If nothing unexpected happens, =app-admin/perl-cleaner-2.14 will go stable in a month. A couple of days ago, like everyone using arch, I upgraded my Gnome desktop to 3.12. Though a few packages failed to build, the upgrade itself went pretty smooth. Hats off to the Gnome herders. Overall, 3.12 feels like a solid and well put together release.
There were a few disappointments. The biggest of which being the removal of changing tab titles in gnome-terminal. I’ll spare everyone a long rant but this is feature I have been using extensively for the better part of a decade and I’m very disappointed to see this useful features go away without much justification.
Material for another blog post maybe. One thing I did notice really quickly is the new geolocation entry in the shell’s main top-right menu. Not being a fan of geolocation, I went out to see how I could turn it off by default system-wide as my system has more than one regular user. Going through dconf-editor, I found the correct setting key: org.gnome.shell.location.max-accuracy-level. This key is an enum and the correct value (at least to my taste) is ‘off’.
Setting this for each user is a matter of running “gsettings set”. However, to change the default value, a little elbow grease is required. GLib’s GSettings is actually an API for various backends.
The one we use on Linux is dconf. So this is what I’ll have to bang on. This basically has all the reasoning behind it all.
I’ll just summarize what I did. Create a /etc/dconf/profile/user with the following content: user-db:user system-db:site. Create a matching ‘site’ settings database (I could have called it anything really) in /etc/dconf/db/site.d/ containing my new default settings file ’00settings’ org/gnome/shell/location max-accuracy-level='off'. Run ‘dconf-update’ which will translate the INI-like settings file into a binary dconf file ‘/etc/dconf/db/site’ Now, I assume GSettings did not pick up this new profile on its own, so I had to restart my session. But from there, all changes to the settings file followed by a ‘dconf update’ automatically propagates to running applications, gnome-shell included. Overall, this was easier than I anticipated.
Hope that helps anyone trying to do similar things. Hello users, TL;DR: x86 (32bit) support is going away soon, if you use Sabayon x8664 (64bit), you can ignore this. In an effort of decreasing our computing and human capacity requirements, I am going to start the process that deprecates Sabayon x86 (32bit) images, package repositories and their support. X8664 (or AMD64) has been introduced one decade ago. Yes, it was 2004, pretty much the same year I started messing with a binary Gentoo-based distro. It’s time to move on, free up resources and focus on what matters. 32bit is not important anymore and modern computers come with tons of GB of RAM.
At the same time, I don’t see x32 going anywhere. Instead, I see the need to standardize on one single x86 architecture. Some distributions have started doing the same, for instance, RHEL 7 will not see any 32bit version. Windows 8, well, yes, said goodbye to 32bit as well. If you are still stuck with 32bit CPUs, there are 5 things you could do:. Make sure that your CPU does not really support x8664.
You may be surprised to know that it might run x8664 code just fine. Given our deprecation roadmap, migrate your stuff over a more recent system.
EBay, Amazon, are your friends. A second-hand x8664 system can cost you less than $100. Migrate to other distros and pray they won’t kill 32bit anytime soon (time is not in your favor). Migrate your Sabayon system to Gentoo/Portage, basically compiling your own stuff. Alternatively, setup your own Entropy repository in order to keep your system up-to-date. Burn your motherboard and CPU by doing insane overclocking and then, when they die, violently hit them with a hammer while screaming “You shall not compute!”.
Our deprecation roadmap is as follows:. June 2014: stop offering x86 images off our download pages, keep them on mirrors. July/August 2014: stop building x86 images as part of our daily and monthly release rollout. October 2014: stop offering x86 images from our mirrors. November 2014: stop offering package updates, including security updates, for x86 images. January 2015: stop offering packages from our mirrors.
After January 2015, you will not be able to install new packages as well. The only way to keep your system up-to-date is to use (plus our overlays) or (by maintaining your own repository). Our x8664 images are multilib, which means that you can run 32bit code on them just fine. As a clustering and distributed architecture enthusiast, I’m naturally interested in software providing neat ways to coordinate any kind of state/configuration/you-name-it over a large number of machines. My quest, as many of you I guess, were so far limited to tools like ( but with ) and (last commit nearly 6 months ago) which both cover some of the goals listed above with more or less flavors and elegance (sorry guys, JAVA is NOT elegant to me). I recently heard about, a new attempt to solve some of those problems in an interesting way while providing some rich fuctionnalities so I went on giving it a try and naturally started packaging it so others can too.
WTF is consul? Consul is a few months’ old project ( and already available on Gentoo!) from. I especially like its datacenter centric architecture, intuitive deployment and its DNS + HTTP API query mecanisms. This sounds promising so far! This is a descripion taken from the Hashicorp’s blog: Consul is a solution for service discovery and configuration. Consul is completely distributed, highly available, and scales to thousands of nodes and services across multiple datacenters. Some concrete problems Consul solves: finding the services applications need (database, queue, mail server, etc.), configuring services with key/value information such as enabling maintenance mode for a web application, and health checking services so that unhealthy services aren’t used.
These are just a handful of important problems Consul addresses. Consul solves the problem of service discovery and configuration. Built on top of a foundation of rigorous academic research, Consul keeps your data safe and works with the largest of infrastructures. Consul embraces modern practices and is friendly to existing DevOps tooling.
This is a RFC and interest call about the packaging and availability of consul for Gentoo Linux. The latest version and live ebuilds so if you are interested, please tell me (here, IRC, email, whatever) and I’ll consider adding it to the portage tree. I want to test it! Now that would be helpful to get some feedback about the usability of the current packaging.
So far the ebuild features what I think should cover a lot of use cases:. full build from sources. customizable consul agent init script with reload, telemetry and graceful stop support. web UI built from sources and installation for easy deployment # layman -a ultrabug # emerge -av consul Hope this interests some of you folks! This release is important to me (and my company) as it officially introduces a few features we developed for our needs and then contributed to uWSGI. Special congratulations to my co-worker @btall for his first contribution and for those nice features to the metrics subsystem with many thanks as usual to @unbit for reviewing and merging them so quickly. If you tried upgrading from stable amd64 to amd64 or otherwise done a big update of perl, you probably hit this weird perl-cleaner slot conflict: # perl-cleaner -all!!!
Multiple package instances within a single package slot have been pulled!!! A couple of days ago, I pushed out a new build of Lilblue Linux 1 which is my attempt to turn embedded Linux on its head and use uClibc 2 instead of glibc as the standard C library for a fully featured XFCE4 desktop for amd64. Its userland is built with Gentoo’s hardened toolchain, and the image ships with a kernel built using hardened-sources which include the Grsec/PaX patches for added security, but its main distinguishing feature from mainstream Gentoo is uClibc.
Even though Lilblue is something of an experimental project which grew out of my attempt to get more and more packages to build against uClibc, the system works better than I’d originally expected and there are very few glitches which are uClibc specific. You get pretty much everything you’d expect in a desktop, including all your multimedia goodies, office software, games and browsers. Mplayer2 works flawlessly! But all is not well in the land of uClibc these days. It has been over two years since the last release, 0.9.33.2 on May 15, 2012, and there are about 80 commits sitting in the 0.9.33 branch, many of which address critical issues since 0.9.33.2. This causes problems for people building around uClibc, such as buildroot, and there has even been talk on the email lists of dropping uClibc as its main libc in favor of either glibc or musl 3.
Buildroot is maintaining about 50 backported patches, while Mike’s (aka vapier’s) latest patchset has 20. I seem to always have to insert a backported patch of my own here or there, or ask Mike to include it in his patchset.
For this release, I did something that I have mixed feelings about. Instead of 0.9.33.2 + backported patches, I used the latest HEAD of the 0.9.33 git branch. This saved me the trouble of getting more patches backported into a new revision of our 0.9.33.2 ebuild, or by “cheating” and putting the patches into /etc/portage/patches/sys-libs/uclibc, but it did expose a well known problem in uClibc, namely the problem of how its header files stack. A libc’s header files typically include one another to form a stack 4. For example, on glibc, sched.h stacks as follows sched.h features.h sys/cdefs.h features.h bits/wordsize.h gnu/stubs.h bits/types.h features.h bits/wordsize.h bits/typesizes.h stddef.h time.h features.h stddef.h bits/time.h bits/types.h bits/timex.h bits/types.h bits/types.h xlocale.h bits/sched.h Here sched.h includes features.h, bits/types.h, stddef.h, time.h and bits/sched.h. In turn, features.h includes sys/cdefs.h and gnu/stubs.h, and so on. Each indentation indicates another level of inclusion.
Circular inclusions are avoided by using #ifdef shields. At least one reason for this structure is to abstract away differences in architectures and ABIs in an effort to present a hopefully POSIX compliant interface to the rest of userland. So, for example, glibc’s sys/syscall.h looks the same on amd64 as on mipsel, but it includes asm/unistd.h which is different on the two architectures.
Each architecture’s asm/unistd.h have their own internal #ifdefs for the different ABIs proper to the architecture, and each #ifdef section in turn defines the values of the various syscalls appropriately for their ABI 5. Another reason for this stacked inclusion is to make sure that certain definitions, macros or prototypes defined in one header are made available in another header in the same way as they are made available in a c file. This is the reason given, for instance, in the uClibc commit which I examine below. Let’s see where uClibc’s header problems begin. Take a look at Gentoo’s, where cdrtools-3.01alpha17 fails to build against uClibc because its readcd/readcd.c defines “BOOL clone;” which collides with the definition of clone in bits/sched.h 6.
Nowhere is sched.h included in readcd.c, instead bits/sched.h gets pulled in indirectly because stdio.h is included! Reveals the stacking problem. Stdio.h’s stacking is complex, but following just the bad chain, we see that stdio.h includes bits/uClibcstdio.h which includes bits/uClibcmutex.h which includes pthread.h which includes sched.h which includes bits/sched.h — wheh! If you’re wondering what stdio.h should have to do with sched.h, then you see the problem: too much information is being exposed here. Joerg’s comment on the bug pretty much sums it up: “The related include files (starting from what stdio.h includes) most likely expose the problem because they seem to expose implementation details that do not belong to the scope of visibility of the using code.” Back to my bump from 0.9.33.2 to the HEAD of the 0.9.33 branch.
Gempak Htt-869970 Decoders For Mac
This bump unexpectedly exposed bugs. Here we find that =media-libs/nas-1.9.4 and =app-text/texlive-core-2012-r1, both of which build just fine against 0.9.33.2, fail against HEAD 0.9.33 because of a name collision with abs. Unlike the case with cdrtools, where the blame is squarely on uClibc, I think this is a case of enough blame to go around. Both of those packages define abs as a macro even though it is supposed to be a function prototyped in stdlib.h, as per POSIX.1-2001 7. At least nas tries to check if abs has been already defined as a macro, but its still not enough of a check to avoid the name collision. Unfortunately, given its archaic imake system, its not as easy as just adding ACCHECKFUNCS(abs) to configure.ac.
Texlive-core at least uses GNU autotools, but its collection of utilities define abs in several different places making a fix messy. On the other hand, why do we suddenly have stdlib.h being pulled in after those macros with HEAD 0.9.33 whereas we didn’t with release 0.9.33.2?
It turns out to be uClibc’s tiny commit which I quote here: sched.h: include stdlib.h for malloc/free Signed-off-by: Bernhard Reutner-Fischer diff -git a/libc/sysdeps/linux/common/bits/sched.h b/libc/sysdeps/linux/common/bits/sched.h index 7d6273f.878550d 100644 - a/libc/sysdeps/linux/common/bits/sched.h b/libc/sysdeps/linux/common/bits/sched.h @@ -109,6 +109,7 @@ struct schedparam /. Size definition for CPU sets./ # define CPUSETSIZE 1024 # define NCPUBITS (8. sizeof (cpumask)) +# include /. Type for array elements in 'cpusett'./ typedef unsigned long int cpumask; Both packages pull in stdio.h after their macro definition of abs.
But now stdio.h, which pulls in bits/sched.h, further pulls in stdlib.h with the function prototype of abs and BOOM! We get /usr/include/stdlib.h:713:12: error: expected identifier or '(' before 'int' /usr/include/stdlib.h:713:12: error: expected ')' before ' token Untangling the implementation details is a going to be a thorny problem. And, given uClibc’s faltering release schedule schedule, things are probably not going to get better soon.
I have looked at the issue a bit, but not enough to start unraveling it. Its easier just to apply hacky patches to the odd package here and there than to rethink uClibc’s internal implementations. If we are going to start rethinking implementation, the musl 8 is much more exciting. UClibc is used in lots of embedded systems and the header issue is not going to be a show stopper for it or for Liblue, but it does make alternatives look like musl more attractive. References: 1 2 3 See to the uClibc community. 4 I wrote a little python script to generate these stacks since creating them manually. You can download it from my dev space:.
Note that the stacking is influenced by #ifdef’s throughout, eg #ifdef USEGNU, which the script ignores, but it does give a good starting place for how the stacking goes. 5 As of glibc 2.17, on mips, asm/unistd.h defines the various NR. values in a flat file with three #ifdefs sections for MIPSSIMABI32, MIPSSIMABI64 and MIPSSIMNABI32, respectively ABI=o32, n64 and n32. Using my script from 4, the stacking looks as follows: sys/syscall.h asm/unistd.h asm/sgidefs.h bits/syscall.h sgidefs.h In contrast, on amd64, each ABI is broken out further into their own file, with asm/unistd32.h, asm/unistdx32.h or asm/unistd64.h included into asm/unistd.h for i386, ILP32, or ILP64 respectively. Here the stacking is sys/syscall.h asm/unistd.h asm/unistd32.h asm/unistdx32.h asm/unistd64.h bits/syscall.h Remember, on both architectures, sys/syscall.h are identical, and that is the file you should include in your c programs, not any of the asm/. which often carry warnings not to include them directly.
Is a multi-language software development environment comprising an integrated development environment (IDE) and an extensible plug-in system. It is written mostly in Java. It can be used to develop applications in Java and, by means of various plug-ins, other programming languages including Ada, C, C, COBOL, Haskell, Perl, PHP, Python, R, Ruby (including Ruby on Rails framework), Scala, Clojure, Groovy, Android and Scheme. It can also be used to develop packages for the software Mathematica.
Development environments include the Eclipse Java development tools (JDT) for Java, Eclipse CDT for C/C, and Eclipse PDT for PHP, among others. Using Eclipse. The GEneral Meteorology PAcKage, is an analysis, display, and product generation package for meteorological data. It is developed by NCEP (the National Centers for Environmental Prediction) for use by the National Centers (Storm Prediction Center (SPC), Tropical Prediction Center (TPC), Aviation Weather Center (AWC), Hydrologic Prediction Center (HPC), Marine Prediction Center (MPC), Environmental Modeling Center (EMC), etc.) in producing operational forecast and analysis products such as those distributed as Redbook Graphics and others displayed on the NWS web pages and utilized internally within the centers. Graphical User Interfaces provide convenient access to interactive data manipulation. A comprehensive set of decoders enables integration of real-time and archive data, products, and bulletins. The GEMPAK distribution consists of a suite of application programs, Graphical User Interfaces (GUIs), meteorologic computation libraries, graphic display interfaces, and device drivers for the decoding, analysis, display and diagnosis of geo-referenced and meteorological data.
![For For](/uploads/1/2/3/7/123760551/416643427.png)
Using GEMPAK. The Grid Analysis and Display System is an interactive desktop tool that is used for easy access, manipulation, and visualization of earth science data.
GrADS has two data models for handling gridded and station data. GrADS supports many data file formats, including binary (stream or sequential), GRIB (version 1 and 2), NetCDF, HDF (version 4 and 5), and BUFR (for station data). GrADS has been implemented worldwide on a variety of commonly used operating systems and is freely distributed over the Internet. Is a desktop and web program for managing and sharing research papers, discovering research data and collaborating online. It combines Mendeley Desktop, a PDF and reference management application (available for Windows, Mac and Linux) with Mendeley Web, an online social network for researchers. Mendeley requires the user to store all basic citation data on its servers - storing copies of documents is at the user's discretion. Upon registration, Mendeley provides the user with 1 GB of free web storage space, which is upgradeable at a cost.
Using Mendeley. (Network Common Data Form) is a set of software libraries and self-describing, machine-independent data formats that support the creation, access, and sharing of array-oriented scientific data. The project homepage is hosted by the Unidata program at the University Corporation for Atmospheric Research (UCAR). They are also the chief source of netCDF software, standards development, updates, etc. The format is an open standard. NetCDF Classic and 64-bit Offset Format are an international standard of the Open Geospatial Consortium. Using NetCDF.
Provide Python interfaces to most of the graphics and file input/output functionality existing in the NCAR Command Language (NCL). A knowledge of NCL would give you a leg up in using these modules, but they are meant to be independent from NCL and used as a stand-alone suite of Python functions. In a few circumstances where the NCL documentation applies directly to PyNGL and PyNIO and there is no ambiguity, links are made to the NCL documentation from the PyNGL documentation. PyNGL and PyNIO represent recent developments in the evolution of a package that dates back several decades. Those who are interested can view the Using python-NGL and python-NIO.
Module can read and write files in both the new netCDF 4 and the old netCDF 3 format, and can create files that are readable by HDF5 clients. The API modelled after Scientific.IO.NetCDF, and should be familiar to users of that module. Most new features of netCDF 4 are implemented, such as multiple unlimited dimensions, groups and zlib data compression. All the new numeric data types (such as 64 bit and unsigned integer types) are implemented. Compound and variable length (vlen) data types are supported, but the enum and opaque data types are not. Mixtures of compound and vlen data types (compound types containing vlens, and vlens containing compound types) are not supported.
Using python-netcdf4.
Malas nk komen bnyk, kerana terselah kejayaan harimau malaya kita, walau kecundang di negara orang (kecundang pown nk bg depa rase kemenangan.huhu.). Bak kata jurulatih indon Alfred Riedl 'Kami mungkin boleh menang dlm perlawanan dijakarta, tapi memenangi piala suzuki adalah mustahil' huhu.
Awal2 die dah tau. Sbb tu muke rilek jer. Tp, mlm td, wak nmpk akan kegigihan indonesia yang cube dan terus mencube untuk menjaringkan goal walaupun mereka tahu bilangan jaringan yang perlu mereka kecapi amatlah banyak. Syabaslah pemain indon, wak tabik korang.
Dan korang adalah pemain yg berwibawa berbanding sebilangan rakyat korang yg masih membenci kami, rakyat malaysia dan juga tidak dpt menerima kekalahan. Tengok la player indon. Xde pun nk gado2. Rakyat indon, cubelah contohi mereka ok. Janganlah nak kutuk kami dengan perkataan 'maling' korang, kerana tanpa negara kami, rakyat korang kat sini x kan dapat kesenangan. Kepada pemain Malaysia, korang tetap hebat pemain Malaysia, walau kalah kat indon kejuaraan tetap kita punya, lagi pown korg mesti dah penat.
Tengok cara korg main pown dah tau. Kepada Ashari jaringan kamu malam tadi amat bermakna dan Khairul Fahmi anda adalah penjaga pintu gerbang terbaik kerana berjaya menyelamatkan banyak jaringan yang hampir mengena dari indon dan terutama sekali sepakan penalti firma ko boleh tangkap dengan kemas. Dan (berapa bnyk dan lah.) kepada Safee Sali, tahniah kerana ternobat sebagai penjaring terbanyak (x silap wak 5 goal kan??) begitu juga K.Rajagobal, tahniah kerana berjaya mendidik pemain anda sehngga berjaya ketahap ini.
Ucapan Tahniah & Terima Kasih dari Wak & Seluruh Rakyat Malaysia kepada nama-nama tersebut. Pengurus Pasukan Dato Subahan bin Kamal Ketua Jurulatih K.Rajagobal Penolong Jurulatih Tan Cheng Hoe Jurulatih Penjaga Gol Mohd Faozi Mukhlas Penjaga Gol Mohd. Farizal Marlias Khairul Fahmi Che Mat Mohd. Sharbinee Allawee Ramli Pertahanan Mohd. Sabre Mat Abu Mohd. Faizal Muhamad Mohd.
Asraruddin Putra Omar Khairul Helmi Johari Mohamad Azmi Muslim Mahalli Jasuli Mohamad Muslim Ahmad Mohamad Fadhli Mohd. Shas Pemain Tengah Safiq Rahim Amar Rohidan Mohd. Khyril Muhymeen Zambri K.
Gurusamy Govandar S. Kunanlan Abdul Shukur Jusoh Mohammad Faizal Abu Bakar Mohd.
Amirulhadi Zainal Baddrol Bakhtiar Mohd. Fandi Othman Mohamad Ashari Samsudin Abdul Halim Zainal Penyerang Norshahrul Idlan Talaha Mohd. Sali Izzaq Faris Ramlan S.