Phu Ha's profileSkinny guy's SpaceBlogListsNetwork Tools Help

Blog


    January 02

    10 điều tuổi trẻ thường hay lãng phí

    Trong hành trình tạo dựng một cuộc đời có ý nghĩa, nếu bạn lỡ coi thường một trong 10 điều thiết yếu dưới đây, coi như bạn đã tự đánh mất một phần nhựa sống của chính mình.

    Sức khoẻ: Lúc còn trẻ, người ta thường ỷ lại vào sức sống tràn trề đang có. Họ làm việc như điên, vui chơi thâu đêm, ăn uống không điều độ…. Cứ như thế, cơ thể mệt mỏi và lão hoá nhanh. Khi về già, cố níu kéo sức khoẻ thì đã muộn.

    Thời gian: Mỗi thời khắc “vàng ngọc” qua đi là không bao giờ lấy lại được. Vậy mà không hiếm kẻ ném 8 giờ làm việc qua cửa sổ. Mỗi ngày, hãy nhìn lại xem mình đã làm được điều gì. Nếu câu trả lời là “không”, hãy xem lại quỹ thời gian của bạn nhé!

    Tiền bạc: Nhiều người hễ có tiền là mua sắm, tiêu xài hoang phí trong phút chốc. Đến khi cần một số tiền nhỏ, họ cũng phải đi vay mượn. Những ai không biết tiết kiệm tiền bạc, sẽ không bao giờ sở hữu được một gia tài lớn.

    Tuổi trẻ: Là quãng thời gian mà con người có nhiều sức khoẻ và trí tuệ để làm những điều lớn lao. Vậy mà có người đã quên mất điều này. “Trẻ ăn chơi, già hối hận” là lời khuyên dành cho những ai phí hoài tuổi thanh xuân cho những trò vô bổ.

    Không đọc sách: Không có sách, lịch sử im lặng, văn chương câm điếc, khoa học tê liệt, tư tưởng và suy xét ứ đọng. Từ sách, bạn có thể khám phá biết bao điều kỳ thú trên khắp thế giới. Thật phí “nửa cuộc đời” cho nhưng ai chưa bao giờ biết đọc sách là gì!

    Cơ hội: Cơ hội là điều không dễ dàng đến với chúng ta trong đời. Một cơ may có thể biến bạn thành giám đốc thành đạt hay một tỷ phú lắm tiền. Nếu thờ ơ để vận may vụt khỏi tầm tay, bạn khó có thể tiến về phía trước.

    Nhan sắc: Là vũ khí lợi hại nhất của phụ nữ. Có nhan sắc, bạn sẽ tự tin và chiếm được nhiều ưu thế hơn so với người khác. Tuy nhiên, “tuổi thọ” của nhan sắc có hạn. Thật hoang phí khi để sắc đẹp xuống dốc. Hãy chăm sóc mình ngay từ bây giờ.

    Sống độc thân: Phụ nữ ngày nay theo trào lưu “chủ nghĩa độc thân”. Thực tế là khi sống một mình, bạn rất cô đơn và dễ cảm thấy thiếu vắng vòng tay yêu thương của chồng con. Bận bịu gia đình chính là một niềm vui. Sống độc thân, bạn đã lãng phí tình cảm đẹp đẽ ấy.

    Không đi du lịch: Một vĩ nhân đã từng nói: “Khi đi du lịch về, con người ta lớn thêm và chắc chắn một điều là trái đất phải nhỏ lại”. Vì thế, nếu cho rằng đi du lịch chỉ làm hoang phí thời gian và tiền bạc, bạn hãy nghĩ lại nhé!

    Không học tập: Một người luôn biết trau dồi kiến thức sẽ dễ thành công hơn người chỉ biết tự mãn với những gì mình biết. Nếu không học hành, bạn đang l=

    December 12

    Học làm quản lý trong 5 phút...

    (Từ Internet, Lemon lược dịch)
    Đây là những bài học cực vui và bổ ích vì triết lý đằng sau câu chuyện. Lemon chắc chắn bạn sẽ rút ra cho mình những điều hay sau khi cười sảng khóai. Enjoy nhé!

    Bài học 1:
    Ông nọ đang tắm thì có tiếng chuông cửa. Người vợ vừa tắm xong choàng vội cái khăn rồi bước ra. Khi bà mở cửa thì thấy ông Bob, tay hàng xóm.
    Bà chưa kịp nói gì thì Bob bảo: “Tôi sẽ đưa cho chị 1000$ nếu chị bỏ chiếc khăn tắm đó xuống”. Sau một lúc lâu suy nghĩ, bà nọ đồng ý và đứng tồng ngồng khoảng vài giây. Ông ta đưa cho bà 1000$ rồi vội vã bước đi.
    Bà nọ choàng khăn và trở vào nhà. Ngang phòng tắm, ông chồng hỏi: “Ai thế em?”. Bà trả lời: “Ông Bob hàng xóm anh à”. “Thật tuyệt!”, ông chồng đáp. “thế ông ấy có nói gì với em về món nợ 1000$ không?”

    Bài học rút ra:
    Nếu chia sẻ những lợi ích và rủi ro của bạn với cổ đông đúng lúc, bạn sẽ có cơ hội tránh được những thiệt hại lớn hơn nhiều. :idea:

    Bài học 2:
    Anh chàng sales, cô thư ký văn phòng và vị giám đốc đi ăn trưa. Trên đường đi họ thấy 1 cây đèn dầu cổ, họ chạm vào nó và Thần Đèn xuất hiện. Thần nói: “Ta sẽ cho mỗi người một điều ước”.
    “Tôi trước!”, cô thư ký la to: “Tôi muốn là một minh tinh ở Hollywood, ai cũng phải ngước nhìn tôi”. Bụp! Cô ta biến mất. “Tôi, tôi” chàng sales lớn tiếng “Tôi muốn đi Hawaii, nằm trên bãi biển đẹp nhất, uống loại whisky ngon nhất, và được matxa bởi những cô nàng xinh đẹp nhất.” Bụp! Anh ta biến mất.
    Vị Thần quay qua ông giám đốc: “Tới ông”. Ngài giám đốc nói: “Okay, tôi muốn cả hai quay trở lại văn phòng ngay sau bữa trưa này.”

    Bài học rút ra:
    Luôn luôn để sếp nói trước. :raider:

    Bài học 3:
    Đại bàng đậu trên cành nghỉ ngơi, thư giãn. Chú thỏ chạy qua, thấy thế bèn hỏi: “Tôi có thể như anh, ngồi thư giãn mà không cần làm gì cả không?”. Đại bàng trả lời “Tại sao không?”. Chú thỏ ngồi xuống ngay phía dưới đại bàng và bắt đầu nghỉ ngơi. Bỗng nhiên Cáo xuất hiện, nhảy xổ tới và ăn thịt chú thỏ tội nghiệp.

    Bài học rút ra:
    Muốn “ăn trên ngồi trốc, việc nhẹ lương cao”, bạn phải ngồi ở rất rất cao. :devil:

    Bài học 4:
    Gà tây nói chuyện với Bò: “Tôi muốn leo lên ngọn cây kia, hixhix, nhưng tôi lại không đủ sức”. Bò nói: “Ồ, tại sao mày không thử phân của tao này? Chúng đầy dinh dưỡng.” Gà tây mổ một ít phân bò, và thật sự cảm thấy nó có đủ sức leo lên cành cây thấp nhất. Ngày hôm sau, nó dùng thêm một ít, và nó có thể leo lên được cành thứ hai. Sau bốn, năm ngày cố gắng, con gà tây thật tự hào vì nó đã leo lên được tới cành cao nhất. “Đoàng!”, bất thình lình nó bị bắn hạ bởi người nông dân.

    Bài học rút ra:
    “Ăn tạp”, “ăn dơ” có thể nhanh chóng giúp bạn leo lên tới đỉnh, nhưng bạn sẽ không trụ lại lâu. :sherlock:

    Bài học 5:
    Một con chim nhỏ bay về phương Nam trong mùa đông. Trời lạnh cóng khiến con chim nhỏ kiệt sức và rơi xuống một cánh đồng. Khi nó đang nằm đó, một con bò đi ngang qua và phọt một bãi phân ngay trên người nó. Nằm trong đống phân, con chim nhỏ lại cảm thấy thật vui vì nó đã ấm dần lên. Đống chất thải của con bò đã thật sự cứu nó. Con chim nhỏ nằm đó, sung sướng và hạnh phúc, rồi nó bắt đầu cất tiếng hót. Mèo nghe thấy, nó lần theo tiếng hót của chim nhỏ, tới đống phân, lôi chú chim ra và ăn thịt nó.

    Bài học rút ra:
    1.Không phải ai “phỉ nhổ” bạn cũng là kẻ thù của bạn. :jester:
    2.Không phải ai lôi bạn ra khỏi rắc rối cũng là tri kỷ của bạn. :yes:
    3.Và khi bạn đang ngập ngụa trong những rắc rối, tốt nhất hãy ngậm miệng lại.
    December 09

    Some cool enterprise products

     
    Alfresco
     
    OSWorkflow - OSWorkflow Overview

    Summary

    OSWorkflow is fairly different from most other workflow systems available, both commercially and in the open source world. What makes OSWorkflow different is that it is extremely flexible. This can be hard to grasp at first, however. For example, OSWorkflow does not mandate a graphical tool for developing workflows, and the recommended approach is to write the xml workflow descriptors 'by hand'. It is up to the application developer to provide this sort of integration, as well as any integration with existing code and databases. These may seem like problems to someone who is looking for a quick "plug-and-play" workflow solution, but we've found that such a solution never provides enough flexibility to properly fulfill all requirements in a full-blown application.

    OSWorkflow gives you this flexibility.

    OSWorkflow can be considered a "low level" workflow implementation. Situations like "loops" and "conditions" that might be represented by a graphical icon in other workflow systems must be "coded" in OSWorkflow. That's not to say that actual code is needed to implement situations like this, but a scripting language must be employed to specify these conditions. It is not expected that a non-technical user modify workflow. We've found that although some systems provide GUIs that allow for simple editing of workflows, the applications surrounding the workflow usually end up damaged when changes like these are made. We believe it is best for these changes to be made by a developer who is aware of each change. Having said that, the latest version provides a GUI designer that can help with the editing of the workflow.

    http://www.opensymphony.com/osworkflow/

     

    MediaWiki

    http://www.installationwiki.org/MediaWiki

     

     

     

     

     

    JPC Key Features Explained

    JPC Key Features Explained

    Cross Platform

    Programs are generally compiled for a specific computer architecture and, once compiled, will only run on that machine (or another like it). Pure Java can be compiled once and run on any platform that has a Java Virtual Machine (JVM). JPC is pure Java, and thus runs on Windows, Linux, MacOS, mobile phones, set-top boxes, ARM boards and anything else with a JVM -- all without the need to build different versions for each platform.

    Secure

    Malicious software in a JPC virtual computer cannot harm your real computer because your real machine is protected by multiple independent layers of security. The first layer is JPC itself, supported in turn by the industry-standard Java virtual machine and then finally scrutinized by your machine's operating system. These layers combine to form an impregnable shield for your computer and data.

    Flexible

    You can interact with the virtual computer through a window on your desktop, or just watch it while a virtual robot taps at a virtual keyboard. The different components of the virtual computer are completely separated. This enables you to use the hard disk of one computer, the CPU of another, while displaying it all on a screen across the network and typing input on a keyboard on a mobile phone.

    The JPC Core

    There are many different computer emulators available, however, emulators for the x86 PC are rare and until JPC there had not been an x86 emulator written in pure Java. This is because the x86 PC is an extremely complex architecture, with a long history of incremental improvements, and therefore a legacy of many subtle features! Consequently everyone believed an x86 emulator written in Java would be far too slow to be of any use.

    JPC is our answer to this challenge: a pure Java x86 PC emulator which currently runs up to 20% native speed. This puts it amongst the fastest emulators of an x86 PC, despite needing only a pure Java environment. At first sight it might seem impossible for a Java based emulator to approach other emulators which use "native" code. However JPC uses a number of optimization strategies to achieve an acceptable speed. In fact these strategies are very similar to those used by modern x86 hardware; e.g. using a RISC microcode set to streamline the x86 instructions. JPC then uses dynamic binary translation to get the best performance.

    In fact, as the HotSpot JVM applies its own optimization strategies on top of JPC, some parts of programs can run even faster inside JPC.

    Real, Protected Mode and all those other modes...

    PC's have two commonly used modes of operation. The first, Real Mode, is more of a historical relic. MS-DOS runs in real mode and all modern PC's start their boot process in real mode. JPC currently runs real mode at up to 20% of native speed. This speed is achieved despite of the fact that Real mode is essentially a 16-bit mode of operation, which is running on a 32 bit Java Virtual Machine. The second, Protected Mode, is a 32 bit mode, to which all modern operating systems switch to during the boot process. In between Real and Protected Mode, are other modes that evolved at various stages of the x86's lifetime. These modes, like Virtual 8086 Mode and 'Unreal' Mode are often not necessary for modern operating systems once they are up and running, however, operations like boot up and graphic initialization still rely on these obscure modes of operation.

    JPC currently has both real and protected mode interpreters - where microcodes are executed one by one, but the real speed comes when code is compiled. The real mode compiler is fairly advanced but the protected mode version is currently less mature. We are also ironing some of the bugs out of our implementations of Virtual 8086 Mode and 'Unreal' Mode interpreters and compilers, and hope to have this technology available soon!

    Check back soon to see improvements.

    Interpreted mode Compiled Mode
    Real Mode
    Protected Mode Beta Alpha
    Virtual 8086 Mode Alpha Alpha
    'Unreal' Mode Alpha Alpha
     
     
     
     

    Welcome to InstallationWiki.org, the home of free software installation tutorials.

    Welcome to InstallationWiki.org, the home of free software installation tutorials.

    InstallationWiki.org is designed to provide you with comprehensive and free guides to installing software. It is an open Wiki for everyone to contribute to.

    The following categories have tutorials for installing a variety of different programs and software. More will be added to accomodate the newly added tutorials. Click on the category to be taken through to a list of the programs and software:

     
     

    Welcome to the home of the iPodLinux Project (http://sourceforge.net/projects/ipodlinux/)!

    Welcome to the home of the iPodLinux Project (http://sourceforge.net/projects/ipodlinux/)! iPodLinux is an open source venture into porting Linux onto the iPod (http://www.apple.com/ipod/). So far, we have successfully ported a customized uClinux (http://www.uclinux.org) kernel to the iPod, and written a simple user interface for it dubbed podzilla. Additional applications and modules have been written, adding many capabilities not found in Apple's firmware.

    iPodLinux is currently safe to install on 1st, 2nd, and 3rd generation iPods. Development is currently on-going on later generations of iPod, including the fourth generation click wheel, mini, U2, Photo/Color, Nano, and Video. Donations always help when it comes to supporting new hardware. Progress can be tracked on the Project Status page or the blog (http://www.ipodlinux.org/blog).

    Fw: Đường đến sự thành công

     
    ----- Original Message -----
    From: Cantavil
    Sent: Friday, December 07, 2007 8:47 PM
    Subject: Đường đến sự thành công

    Chắc chắn bạn không muốn sự nghiệp của mình chỉ giậm chân tại chỗ. Vậy bạn có biết cách để vươn lên, hãy học hỏi những điều dưới đây.

    1. Phát triển tốt thói quen làm việc. Hoàn tất công việc đúng thời hạn và tránh việc trì hoãn.

     

    2. Nghiên cứu sâu rộng về nguồn gốc lĩnh vực công việc của bạn, để trình độ chuyên môn được phát triển bởi một chương trình nghiên cứu uyên bác. Vì vậy bạn sẽ có một vốn hiểu biết sâu rộng và khả năng phát triển tay nghề cao.

    3. Làm việc cùng với nhóm. Học hỏi từ những đồng nghiệp khác đồng thời chia sẻ vốn hiểu biết của bạn.

    4. Hiểu biết cả hai mục đích công việc của bạn và của nhóm, chắc chắn tất cả đều đồng lòng cùng hướng đến một con đường tiến bộ hơn.

    5. Đặt mục tiêu, viết chúng ra, tiến hành công việc sàn lọc, đánh giá và thực hiện.

    6. Hiểu biết mục tiêu của khách hàng và đối tác, tiến tới vạch kế hoạch học hỏi những giá trị từ họ.

    7. Đừng gian lận. Sẽ không qua được sự giám sát của sếp.

    8. Tình nguyện làm những công việc không thuộc trách nhiệm của bạn: Chấp nhận sự chuyển nhượng từ công việc của các bộ phận khác, tình nguyện tham gia vào vai trò huấn luyện cho các khóa tập huấn, tham gia viết báo cho tạp chí chuyên nghành nội bộ của công ty.

    9. Xây dựng kỹ năng truyền đạt. Nuôi dưỡng niềm đam mê bằng việc đọc nhiều sách theo chủ đề và chú tâm nghiên cứu chúng.

    10. Tạo ra sự mạo hiểm để phát triển bản thân, thừa nhận những thế mạnh và điểm yếu kém của mình. Cố gắng duy trì thế mạnh và sửa chữa những mặt yếu kém.

    11. Tìm kiếm và học hỏi sự thành công của những người nổi tiếng từ trong và ngoài công ty.

    12. Luôn luôn tìm kiếm cơ hội để vươn lên.

    13. Nếu sếp không làm nổi bật những kiến thức và thành tích của bạn, thì tự bạn hãy làm điều đó.

    14. Hãy nghĩ đến những điều lớn lao, nhưng luôn giải quyết tốt những điều chi tiết nhất.

    15. Quản lý được sự liều lĩnh và mạo hiểm của bạn.
    HRvietnam
     
    November 25

    Lesson learn for managing my time and my learning

    From: Cantavil
    Sent: Sunday, November 25, 2007 10:02 PM
    Subject: Lesson learn for managing my time and my learning

    Thời gian trôi qua nhanh thật. Một tháng vừa qua thực sự là một ác mộng, ngày nào tôi cũng đi làm về trễ.
    Lỗi là do tôi, lẽ ra tôi phải chú tâm đến công việc nhiều hơn ngay từ ban đầu!
    Nhưng hôm nay thì mọi việc cũng tạm ổn, và qua đây tôi cũng học được nhiều bài học kinh nghiệm.
     
    Hôm nay cafe 25 Tú Xương, tôi lướt mắt trên mục lục của cuốn sách C# mà thấy buồn và thất vọng vô cùng. Tôi thấy mình chỉ cần cù, chưa thực sự thông minh trong cách học và sữ dụng thời gian.
    1. Học mà không hành thì sẽ mau quên.
    Tôi đã đọc rất nhiều sách, nhưng vì tham lam mà tôi không dành nhiều thời gian hơn cho việc thực hành
     
    2. Hành mà không học
    Đến khi cần làm việc thì không đọc sách, (vì bị thời gian rượt đuổi) hiệu quả công việc không cao, đến khi đọc lại sách thì thấy đã có sẵn mọi thứ
     
    3. Phải chọn đúng sách, đúng nhu cầu mỗi thời điểm, vì như thế sẽ có nhiều cơ hội học xong là thực hành liền, và trước khi làm việc thì cũng đã được trang bị kiến thức
     
    => Tôi phải cố gắng để thời gian rượt đuổi mình, chứ không thể mãi cứ chạy theo deadline được
     
    Lúc này thì tôi thấy mình cần 3 loại sách
    1. Quản lý dự án
    2. Automation Best Practice
    3. C#
     
    Chợt tôi có một sáng kiến, sao mỗi bài học tại sao mình không làm slide PPT nhỉ, đó cũng là một cách để dễ nhớ và dễ cho tham khảo sau này
     
    Chúc một tuần mới suôn sẽ


    Be a better sports nut! Let your teams follow you with Yahoo Mobile. Try it now.

    October 25

    FW: Seven Areas Where Linux Could Get Better

     

     


    From: Phu Ha [mailto:vinhphu3000@yahoo.com]
    Sent: Thursday, October 25, 2007 12:53 AM
    To: Ha, Phu Vinh
    Subject: Seven Areas Where Linux Could Get Better

     

    Seven Areas Where Linux Could Get Better

    Not all these features will get in, showing the stop-and-go road for improvements to make their way into the Linux kernel.

    By Charles Babcock,  InformationWeek
    Oct. 20, 2007
    URL: http://www.informationweek.com/story/showArticle.jhtml?articleID=202404645

    To a business user of Linux, the development of its kernel may appear so Byzantine, with dozens of people maintaining different pieces and hundreds more volunteers submitting code, that it's hard to see where new features are headed.

    There is no Linux road map, per se. To give a glimpse of the process, here are seven areas of development worth watching, based on interviews with developers and kernel maintainers, and time on www.kernelnewbies.org. Not all are moving ahead smoothly, illustrating the stop-and-go path improvements must travel to get into the kernel.

    1

    Virtualization

    Recognizing virtualization as a "megatrend" of the decade, Linux kernel maintainers have made it a priority to add virtualization features to the kernel at a rapid pace. The hypervisor KVM, contributed by Avi Kivity of startup Qumranet, was included in the kernel of late 2006 and updated in last month's release. But it's an example of the conflict between rapid kernel releases and the slower-advancing enterprise editions.

    "KVM is a very good example of things we think are not enterprise-ready," says Holger Dryoff, VP of management at Novell. KVM needs more testing on how it interacts with kernel subsystems, including the scheduler, he adds, before it gets into SUSE Linux Enterprise Server.

    XenSource, the commercial open source virtualization company recently bought by Citrix Systems for $500 million, has lobbied to get the Xen hypervisor in the kernel with its own architecture, much as a new chip would. Kernel maintainers contend that's a maintenance-heavy way to add a virtualization feature. XenSource engineers have conceded, but work remains to get Xen aligned with the kernel's operations. It hasn't made it into the kernel, beyond just-added support that lets Linux recognize when it's running in a virtualized environment.

    Other virtualization features are moving faster, including KVM and Lguest, a minimalist 5,000-line hypervisor written by IBM engineer Rusty Russell that's included in the most recent kernel. Like KVM, it taps the virtualization hooks in the latest chips from Intel and Advanced Micro Devices. Unlike VMware's ESX Server, however, Lguest creates a virtual machine whose operating system realizes it has been virtualized. This architecture lets the operating system more efficiently pass some calls for CPU cycles straight to the hardware instead of slowing things down by acting as an intermediary.

    2

    Real-Time Operations

    Linux has been rapidly improving in real-time operations and is now a frequently used embedded system in cell phones and other devices. But the recently issued 2.6.23 kernel shows "a little bit of regression" in real-time operations, says Jim Ready, CTO and founder of MontaVista, a maker of commercial embedded Linux. A new process scheduler tilted more toward "fairness"--the notion that tasks the end user tells the processor to do should get more priority.

    "A real-time guy doesn't want fairness," says Ready, since real-time advocates want the operating system to interrupt whatever the CPU is doing and assert a new priority over it. A simple example is that the software in a medical device monitoring a patient's breathing should send an immediate alert if breathing stops, interrupting whatever process the software's doing. MontaVista won't incorporate the new kernel into its product line until performance is restored, Ready says. Gartner analyst George Weiss predicts standard Linux will be competitive as a real-time system in 2008.

    3

    Interrupt Handlers

    One reason Weiss can say that is because kernel developers are working on giving the scheduler another real-time characteristic. One key role for the operating system is to manage interrupts--to decide which tasks should grab the CPU's attention and how to prioritize different actions. If all the interrupt handlers can be combined into their own thread, that thread can be scheduled and prioritized instead of occurring unpredictably and delaying real-time responses.

    Work on such an approach has been going on for three years. MontaVista's Sven-Thorsten Dietrich submitted code back in 2004 in hopes of preventing interrupt handlers from tying up the kernel for routine tasks, since they hurt real-time response. But that code was too disruptive to get past Ingo Molnar, the kernel's scheduler domain expert. The code trespassed on a key kernel feature, spinlocks, which tie up the CPU as a process waits for a needed bit of data or an event. Many processes rely on spinlocks. Dietrich's code reduced hundreds of spinlocks to 30; Molnar's revision kept 90 spinlocks, a less disruptive change.

    The collection of interrupt handlers into a separate thread now appears ready to go into the kernel. "Ingo replaced what we did, but his work is good," says Ready. MontaVista wouldn't mind more credit for the work it did, but Ready knows this is how open source collaboration works, and he'll settle for real-time changes progressing into the kernel.

    4

    Security

    Everyone wants more secure systems. Novell distributes AppArmor with its SUSE Linux Enterprise Server 10 as a way of limiting how much of the operating system an application can access, thus limiting the damage if the app is accessed without authorization. Still, it's not likely to be included in the kernel any time soon.

    A key Linux security authority, Stephen Smalley--developer of another security scheme, SELinux--argues that AppArmor couldn't be merged into the kernel because its protective mechanism is based on a "pathname" approach, essentially a whitelisting scheme in which AppArmor allows access to only those named files for an application, and all others are excluded. According to a report last year by Jonathan Corbet, Smalley believes an artful intruder could use the approved pathnames to guess additional names, creating an unwanted exposure.

    Kernel maintainer Andrew Morton agrees that this fundamental objection to the pathname approach has kept AppArmor out of the kernel. "I'm not a security programmer," he says. "I don't know how to get that one unstuck."

    5

    System Diagnostics

    Solaris has DTrace for probing what's going on in the heart of the operating system, but Linux is short of user-friendly diagnostic tools. One of the few existing tools is ptrace, which lets one process track the actions of another. But ptrace is clumsy to use and prone to error, and now a replacement, utrace, has made it as far as Morton's memory management tree, one of the last hurdles before submission to Linus Torvalds. Utrace can track the behavior of a process as it's executed by a program, without some of ptrace's problems, but it still causes locking problems in the kernel. Corbet predicts inclusion is unlikely in the next kernel.

    6

    File Systems

    The Reiser4 file system has been under consideration for addition to the kernel, which already contains 30 file systems. It's a large file management system, good at handling a large number of small files while using the minimum of disk space, according to Hans Reiser's documentation.

    The file system requires a file operation to either be completed or disallowed, eliminating the hazard of files corrupted by half-completed operations. It would seem ideal for many Linux uses, but after years of debate, Reiser4 hasn't made it into the kernel. It doesn't fit well with parts of the kernel, and Reiser has dropped out as lead developer. "It will need a new champion if it is to eventually become part of mainline Linux," wrote Corbet in his forecast on its prospects earlier this month.

    ZFS, Sun Microsystems' 128-bit file system, multiplies Linux's address space beyond the needs of the largest systems in use today. Parties that admire it point out that its open source code should be considered for the kernel. But its current license isn't compatible with Linux GPL.

    7

    Power Management

    Linux lags in power management, where Windows laptops have scored impressive gains, spurring Intel engineers, kernel developers Molnar and Thomas Gleixner, and others to push for progress. A year ago, the kernel got "tick-less idle," telling the processor to stay in an idle state when there's no work to be done. Without it, the CPU's clock would ask the kernel 1,000 times per second for something to do, chewing up electricity.

    Dirk Hohndel, chief Linux technologist at Intel, expects more improvements to power management. But any change between the kernel and the system clock threatens many other interactions. "These things can be very difficult and take a long time," he says. "I think that's the right way to do it."

    Illustration by Dale Stephanos

     __________________________________________________
    Do You Yahoo!?
    Tired of spam? Yahoo! Mail has the best spam protection around
    http://mail.yahoo.com

    This email may contain material that is confidential, privileged, and/or attorney work product for the sole use of the intended recipient. Any review, reliance, or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

    10 Warning Signs of Project Failure

     

     


    From: Phu Ha [mailto:vinhphu3000@yahoo.com]
    Sent: Thursday, October 25, 2007 12:52 AM
    To: Ha, Phu Vinh
    Subject: 10 Warning Signs of Project Failure

     

    10 Warning Signs of Project Failure
    By
    Allen Bernard
    October 18, 2007

    Unless you are in a mature industry such as banking or insurance, where information is the life-blood of what you do, chances are you will be familiar with at least some of these 10 project management failings put together by Robert Francis Group analyst Mimi Ho.

    "One, they're right on the button and two, if you take a look at the large majority of them, it all has to do with project planning and early stages of analysis that companies like to jump over," said Jeff Monteforte, owner of Exential, an independent project management consultancy in Cleveland, Ohio.

    In other words, when IT projects fail it rarely is a result of the technology. At its core, project management is all about people.

    "Even in some of our clients, some of them are doing very well … and others are just starting where they don't even have executive support and they get the executives saying 'Just start the project I don't care what you do'," said Ms. Ho. "And projects fail … and they're like 'It's IT's fault.'"

    The Top 3 problems Monteforte, a 20-year veteran of the project management business, encounters most often are: lack of executive support; changes to project scope and the lack of change management; and failure to establish user expectations which leads all too often to unrealistic deadlines.

    The Top 3 project killers he encounters are: lack of executive support; lack of pre-project planning; and insufficient people (not monetary) resources allocated to get the project done.

    Ms. Ho also sees the same problems—especially lack of executive support—as Monteforte but adds poorly defined project requirements to his lists.

    "You need to speak with stakeholders directly because the bill changes or they visualize the project being a certain way but when it's communicated the project could be different," said Ms. Ho.

    According to RFG and Ms. Ho, what follows, in no particular order, are the 10 most common pitfalls to successful project completion:

    Undefined or poorly defined project requirements. - Project managers should collaborate directly with key project stakeholders to define specific detailed project requirements and deliverables. Defining specific project requirements is necessary to maintain alignment of project tasks to desired business outputs, as well as to ensure that projects have clear and specific project objectives established.

    While this step may seem obvious, many companies will skip this stage and go right to solutions to jump start a project. Business and/or IT executives assume the requirements (such as controls, dashboards, data, dependencies, functionality, integration, metrics, outputs, and workflow) are met without performing any confirming analysis.

    These projects tend to fail and the companies usually encounter over spending, project restarts, rework, and/or unmet expectations.

    Lack of project planning. - Once the requirements are known, then conducting thorough, upfront project scope planning is an essential next step to help project managers and stakeholders accurately and clearly define project scope.

    It is important for people to understand that there is more than one way to achieve the requirements and that scope and cost vary by approach. Project scope management is therefore necessary to develop reasonable project estimates, enhance the management of customer and stakeholder expectations, and mitigate project risks such as cost overruns and schedule delays.

    Project managers should establish and standardize a scope management process to develop concise project scope statements and credible budget and schedule estimates.

    Lack of or poorly developed budget forecast. - Thorough research and preparation is necessary to develop a reasonable budget estimate. Many companies will skip this step or just do a very rudimentary estimate due to the amount of work needed to complete the task.

    Some companies that do not maintain internal archives of project costs turn to external consultancies to acquire external spending/budget information on companies that have completed similar projects in a similar market.

    Using the estimated budget, project managers should collaborate with stakeholders to help further refine the project scope and final deliverables. Project managers should use their initial budget to base actual spending plans as well as to proactively track spending and respond quickly to potential issues to prevent shortfalls in the budget.

    Lack of stakeholder involvement. - Project managers should ensure that primary project stakeholders are involved with the project from the beginning and throughout the entire project. This is crucial to ensure that visions are properly communicated, defined, and verified.

    It is very common for project efforts to be delegated to staff that do not have sufficient knowledge or understanding of the desired effort. As a result, projects are defined incorrectly and the projects delivered do not meet the expectations of key stakeholders.

    Lack of executive support. - An IT project can be highly political and may end up involving an excessive number of unnecessary or incorrect participants. IT executives should seek ongoing senior management endorsement and enforcement of the planning process to keep the effort on track and to minimize pushback from line of business (LOB) managers.

    Support from senior management and staff involvement are both needed to drive and keep the effort focused and moving. Ownership of the project must be shared to satisfy the demands of user management. IT executives must convey this message to senior management to retain involvement and participation.

    Frequent or large changes to project scope. - Scope changes can significantly impact the cost, schedule, risks and quality of the entire effort. Project managers should watch out for early and frequent changes to the project scope.

    While scope is defined early in the planning and estimation phases, there are valid reasons for change. For example, a stakeholder may acquire additional insight into a problem during the course of the project or external market conditions and/or government regulations can drive requests that extend beyond the initial project scope. However, changes to project scope can also occur as a result of developing a poor initial scope document.

    Project managers must ensure that adequate time is spent on defining and refining the work effort directly with key stakeholders.

     __________________________________________________
    Do You Yahoo!?
    Tired of spam? Yahoo! Mail has the best spam protection around
    http://mail.yahoo.com

    This email may contain material that is confidential, privileged, and/or attorney work product for the sole use of the intended recipient. Any review, reliance, or distribution by others or forwarding without express permission is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

    7 cách để sếp quí trọng bạn

    7 cách để sếp quí trọng bạn

    Bạn có muốn biết làm cách nào để nhanh thăng tiến? Hãy lắng nghe những điều mà hầu hết các ông chủ phải lên tiếng. Theo đó, bạn sẽ biết được những mong muốn của sếp, hãy học hỏi từ những điều đó, bạn sẽ nhanh chóng được sếp xem là một nhân viên sáng giá của ông ta.

    1. Đừng hỏi những câu hỏi mà bạn có thể trả lời được

    “Tôi phải nhận hàng trăm câu hỏi mỗi ngày. Phần lớn những câu hỏi đó đều là những câu mà nhân viên của tôi có thể tự trả lời được. Họ đúng là những kẻ lười biếng”.

    Vâng, để khuyên giải hãy hỏi sếp của bạn khi bạn thiếu niềm tin hay cảm thấy cần sự ủng hộ của họ.Nhưng trước tiên hãy hỏi chính bạn: “Họ có thể trả lời bất cứ mọi thứ tốt hơn mình hay không?” Trong hầu hết mọi trường hợp đều không thể. Chính bạn là người hiểu biết công việc của mình chính xác hơn ai khác, phải biết cách xoay sở mọi thứ thông qua câu hỏi đầu tiên đó.

    2. Giải quyết: Không vấn đề gì

    “Họ quấy rầy tôi khi họ đến gặp tôi với những vấn đề và mong chờ đưa ra một giải pháp”.

    Đừng đến với sếp của bạn bằng những vấn đề mà bạn có khả năng giải quyết được. Sẽ gây ấn tượng tốt nếu bạn đến với những vấn đề thực sự khó và đề nghị đưa ra phương cách để cùng nhau giải quyết chúng.

    3. Đừng bao giờ nói lời “Xin lỗi”

    “Tôi yêu quí nhân viên của mình khi họ biết tự chịu trách nhiệm cho những sai lầm của họ”.

    Đó là một lối đi đúng đắn. Khởi đầu bằng một lời xin lỗi sẽ làm tăng cái nhìn yếu kém về bạn. Bước kế tiếp để sửa đổi sai lầm là hãy cố gắng nói “Tôi nghĩ dự án này có thể có cách làm cho nó tốt hơn” hoặc “Tôi nghĩ tôi có thể làm cho nó khác với dự án cũ”. Sếp của bạn sẽ rất hài lòng vì cách sửa đổi sai lầm của bạn để cải thiện nó tốt hơn, và ông ta sẽ tập trung vào những gì mà bạn đã học hỏi được từ những sai lầm trước đó.

    4. Đừng dễ xúc động

    “Tôi chán ngấy những email đầy ủy mị của nhân viên gởi đến”.

    Đừng gởi liên tục một email trong lúc tâm trạng của bạn đang buồn phiền và thất vọng. Nó sẽ làm giảm đi cái nhìn tốt về bạn đối với sếp. Nếu buồn phiền hãy viết chúng ra hết nhưng đừng dại dột mà gởi cho sếp vì đó chỉ là một cảm xúc tức thời. Hãy biết kiềm chế, vì chỉ trong vài tiếng đồng hồ sau đó là bạn sẽ bình tĩnh lại, bạn sẽ thấy những điều mình viết ra thật ngớ ngẩn.

    5. Đừng sỉ nhục khả năng hiểu biết của sếp

    “ Khi mọi người gởi cho tôi một email nói rằng họ bị bệnh nặng nên không thể đi làm được, điều đó rõ ràng là họ đang nói dối”.

    Việc gởi đi một email hay gọi điện báo ốm đến phòng nhân sự thì chắc chắn bạn đang bị bệnh thật. Đừng nghĩ bạn có thể qua mắt được cấp trên, một người từng trải và đầy kinh nghiệm.

    6. Đặt ra những câu hỏi và cho đi những ý kiến phản hồi

    “Tôi trân trọng những ý kiến phản hồi từ cấp dưới của tôi, điều đó luôn bổ ích cho công việc”.

    Những thông tin trong công việc luôn bổ ích cho nhau. Nếu những ý kiến của bạn được sếp ủng hộ và đồng tình, hãy nói với ông ta rằng: “Tôi rất cảm kích sự ủng hộ của sếp về những gì mà tôi đã nêu lên trong cuộc thảo luận đó”, sẽ làm ông ta ghi chép lại những công việc liên quan đến bạn. Đưa ra những thông tin phản hồi chính xác, sẽ làm tăng thêm khả năng hiểu biết của bạn và để lại ấn tượng tốt trong mối quan hệ công việc giữa bạn với sếp.

    7. Luôn đưa ra những ý tưởng sáng tạo

    “Tôi đã ghi chép từ đầu đến cuối những hoạt động của một nhân viên, người đã luôn luôn đưa ra những ý tưởng mới cho công việc”.

    Tất cả chúng ta đều có nhiều sự đề nghị về việc làm thế nào để cải thiện mọi thứ trong công việc, và đưa ra những ý tưởng cho các dự án mới. Đừng gởi cho sếp của bạn một list dài những ý tưởng, mà chỉ nên chọn lọc ra một vài ý tưởng hay nhất, khác biệt với các đồng nghiệp khác. Sếp của bạn sẽ không chỉ khâm phục những sáng kiến của bạn, mà còn khen ngợi tính chủ động của bạn để làm cho mọi thứ đều có thể xảy ra.
    HRvietnam
    September 15

    What is good code

  • Simplicity means you don't do in ten lines what you can do in five...
  • Readability means what it says: that others can read your code...
  • Modularity means your program is built like the universe...
  • Layering means that internally, your program resembles a layer cake...
  • Design means you take time to plan your program before you build it...
  • Efficiency means your program is fast and economical...
  • Elegance is like beauty: hard to describe but easy to recognize...
  • Clarity is the granddaddy of good programming, the platinum quality all the others serve.
     
  • September 13

    Khái niệm cơ bản về OOP. Help me

    http://www.vninformatics.com/forum/topic/28803/Khai-niem-co-ban-ve-OOP-Help-me.html;jsessionid=B1BBD0927A9512B047B93A5821783AC0?page=2

    Hello,

    2 bài trả lời đã chứa nhiều thông tin cụ thể, tôi chỉ muốn thêm vài ý cho vui cửa nhà :-) 1. Inheritance là để thể hiện quan hệ IS-A (xe hơi là một phương tiện giao thông)

    class Vehicle() {

    }

    class Byke: public Vehicle (extends in Java)

    {

    }



    2. So sánh multiply inheritance Inheritance trong C++ và Java:



    C++:

    -pro: thừa kế implementation của các lớp base -> reuse code

    -contra: phức tạp, dễ nhầm lẫn



    Java:

    multiply inheritance với single [class] inheritance và interface inheriting

    -pro: giảm comlexity

    -contra: phải viết nhiều code cho inheriting class



    -> interface la giải pháp cho multiply inheritance trong Java chứ không phải là điểm yếu, interface cũng là object.



    3. Design consideration: Inheritance vs. Composition

    Thí dụ bạn muốn modelling các quan hệ để thể hiện 1 cái xe hơi

    Bạn có thể dùng

    - Inheritance:

    Lớp Base CarComponent

    Lớp inherited Engine, Wheel, Window, Door..



    - hoặc Composition. Đây là quan hệ Has-A (xe hoi co motor, 4 banh, 2-4 cửa sổ, 1 tay lái).

    Xem qua cũng thấy Composition phù hợp với suy nghĩ của của con người hơn. Tốt nhất là xài cả hai.



    Thi du C++:

    class IFDriveable {

    string name; // data in "Interface"

    virtual void drive()=0; // make class abstract

    }



    class Engine {

    public:

    void start() const {}

    void stop() const {}

    };



    class Wheel {

    public:

    void turn(int angle) const {}

    };



    class Window {

    public:

    void rollup() const {}

    void rolldown() const {}

    };



    class Door {

    public:

    Window window;

    void open() const {}

    void close() const {}

    };



    class Car : public class IFDriveable {

    public:

    Engine engine;

    Wheel wheel[4];

    Door left, right;



    virtual void drive(){cout << "Bum, bum, bum" << endl;}

    };



    // Test method

    int weAreDrivingFarAway() {

    Car car;

    car.left.window.rollup();

    car.drive();

    car.wheel[0].turn(45);

    }



    3. Pure Interface và abstract class:

    -Khi bạn implement một Interface là bạn đã ký 1 hợp đồng (contract) là sẽ implement các Interface methods.

    -Trong Java thì interface là pure, không có data như bên C++ (xem ví dụ IFDriveable trên). Thay vì đó bạn có thể bỏ data vào abstract

    class, thí dụ như sau: Interface ShapeInterface

    {

    void draw();

    }



    abstract class Graphical extends Object implements ShapeInterface

    {

    protected Point lowerLeft; // lower left of bounding box

    protected Point upperRight; // upper right of bounding box



    public void setPosition(Point ll, Point ur)

    {

    lowerLeft = ll;

    upperRight = ur;

    }



    abstract void draw(); // abstract method

    }

    Giờ bạn không thể tạo một object của lớp Graphical do lớp này là abstract. Bạn phải tạo một lớp thực, thí dụ Rectangle và viết concrete

    implementation cho phương thức draw:

    class Rectangle extends Graphical

    {

    void draw()

    {

    // Really does the drawing

    moveTo(lowerLeft.x, lowerLeft.y);

    lineTo(upperRight.x, lowerLeft.y);

    lineTo(upperRight.x, upperRight.y)

    lineTo(lowerLeft.x, upperRight.y);

    }

    }

    That's just simple, is it?



    4. Template trong C++ : có người coi như là 1 kiểu makro để reuse code cho nhiều typs khác nhau. Khi trình dịch gặp template sẽ chèn

    code phù hợp với typ của bạn vào.

    -pro: code reuse

    -contra: không OOP (thí dụ c++ stl không phải thiết kế OOP nhưng vẫn được AnsiC ++ chấp nhận là thư viện chuẩn)



    Java chủ trương từ đầu là không đưa template, theo tôi có 2 lý do:

    -template là generic progamming paradigm, không phải OOP paradigm trong khi Java muốn từ đầu 100% OOP,

    -Cài đặt 1 cơ chế template cho Java interpreter và virtual machine hiệu quả như trong C++ và native environment không phải trivial

    task.

    Nhưng sau một thời gian ngó lại về C++ template, thấy người ta tuy không OOP bằng, nhưng để giải quyết cùng 1 vấn đề thì phải viết ít

    code hơn. Mấy anh LTV quen C++ template đều lên tiếng đòi feature nay nên Java sắp tới mới đưa vào. Sẽ có cả lợi và hại như phân tích ở trên!



    5. Tóm lại:

    -cả C++ và Java đều cho phép design và implementation với OOP (inheritance, polymorphysm, late binding..), sự khác nhau có thể gọi

    là không nhiều, -Mục đích của mấy thứ này để ta viết được code đơn giản, sạch sẽ và có thể xài lại dễ dàng (reuse),

    -Multiple inheritance trong C++ nên tránh, thay bằng composition. Có người nói Multiple inheritance như cái dù, bạn không phải xài khi

    không cần. Nhưng nếu đi du lịch bắng máy bay hành khách thì tất nhiên bạn có thể đem theo, không ai cấm. Nếu máy bay rớt thì có thể có lợi (thật không? riêng tôi chưa thấy 1 critical project nào lại xài multiple inheritance),

    - Vậy nên nếu bạn chưa quen hai thứ multiple inheritance và template trong C++ cũng không có gì đáng ngại. Hãy bắt đầu bằng những

    cái đơn giản. Sang Java thì cố gắng nắm thêm interface reuse và implementation reuse, thực ra đã implicit có hết trong C++ rồi nhưng khi sang Java lại được explicit nhấn mạnh thêm bằng các từ khoá mới, như là phát minh ra tên lửa vượt đại châu vậy!



    Happy coding!

    tha phuong



    September 04

    Gom tất cả các website rao vặt, việc làm lại thành một website

    Bạn chỉ cần đăng tin trên một website, tin của bạn sẽ được post lên trên tất cả các website khác
    Bạn chỉ cần vào một website, bạn sẽ xem được tin rao vặt của tất cả các website khác
    Tương tự như vậy cho website việc làm

    Mạng xã hội - Mô hình phát triển

    Cái này mới học lóm: 1) Bộ phận nghiên cứu, chiến lược, ra yêu cầu phát triển 2) Bộ phận TA, thiết kế kiến trúc hệ thống 3) Bộ phận lập trình 4) Bộ phận thiết kế đồ họa 5) Bộ phận test website 6) Bộ phận content, nhập dữ liệu 7) Bộ phận marketing, tiếp thị

    Một vài ý tưởng kinh doanh đây

    Nội dung số: Thư viện hình ảnh
    Ngoài việc kinh doanh thông thường, tôi còn có ý định như sau: Cuộc thi ảnh du lịch, để promote cho du lịch của một địa phương. Sữ dụng làm ảnh tư liệu cho các công ty du lịch.

    Sữ dụng ảnh, cuộc thi ảnh để promote cho các hãng bán máy ảnh, thiết bị ảnh, v.v.

    Đầu thu truyền hình kỹ thuật số tích hợp, video on demand, voip, media, youtobe, image, v.v.

    Hosting free cho dữ liệu, một dạng của backup dữ liệu cho người dùng cuối (2 hình thức miễn phí: miễn phí theo dung lượng cố định, thời gian vô hạn; miễn phí theo dung lượng không giới hạn, nhưng thời gian có giới hạn)
    Tiện lợi của việc triển khai dự án này là chi phí thấp, rủi ro thiệt hại khi mất mát dữ liệu lưu trữ miễn khí của khách hàng người dùng cuối là không có

    In name card miễn phí, lấy thông tin dịch vụ: địa chỉ, dịch vụ, điện thoại làm cơ sỡ dữ liệu