After a year and a half of using a mac I can say for certain that it's a far more secure environment than windows. I can't imagine ever doing anything important on a windows machine ever again, back when I used windows for work re-installing the entire operating system was a monthly routine, about 90% of these incidents were virus related despite heavy use of system intensive anti-virus software, firewalls, anti-spyware software, and every other effort to prevent it.

While reading a debate on a tech-blog between the commenters of a provocative post polling whether or not you use anti-virus software and why, I ran across a link to an article written almost 2 years ago at InfoWorld [http://weblog.infoworld.com]. The point argument: which is the safer operating system--Windows or OS X, and the old claim that the reason there are no mac viruses* is due to Apple's small market share (of millions and millions of customers). The following is an excerpt from the article listing some of the technical holes that exist in Windows and not in OS X that would allow a virus to get into your system, and hide. Since it's writing Apple has released a Leopard which is even more secure than previous versions, while Microsoft has done the same, most of these flaws still exist in Vista where the most tangible security improvement being disabled by most users due to it's irritating nature.

...

• All Windows background processes/daemons are spawned from a single hyper-privileged process and referred to as services.

• By default, Windows launches all services with SYSTEM-level privileges.

• SYSTEM is a pseudo-user (LocalSystem) that trumps Administrator (like UNIX's root) in privileges. SYSTEM cannot be used to log in, but it also has no password, no login script, no shell and no environment, therefore

• The activity of SYSTEM is next to impossible to control or log.

• Most of the code running on any Windows system at a given time is related to services, most or all of which run with SYSTEM privileges, therefore

• Successful infection of running Windows software carries a good chance of access to SYSTEM privileges.

• Windows buries most privileged software, service executables and configuration files in a single, unstructured massive directory (SYSTEM32) that is frequently used by third parties. Windows will notify you on an attempt to overwrite one of its own system files stored here, but does not try to protect privileged software.

• Microsoft does not sign or document the name and purpose of the files it places in SYSTEM32.

• Windows has no equivalent to OS X's bill of materials, so it cannot validate permissions, dates and checksums of system and third-party software.

• Windows requires that users log in with administrative privileges to install software, which causes many to use privileged accounts for day-to-day usage.

• Windows requires extraordinary effort to extract the path to, and the files and TCP/UDP ports opened by, running services, and to certify that they are valid.

• Microsoft made it easy for commercial applications to refuse a debugger's attempt to attach to a process or thread. Attackers use this same mechanism to cloak malware. A privileged user must never be denied access to a debugger on any system. My right to track down malware on my computers trumps vendors' interests in preventing piracy or reverse-engineering. Maintaining that right is one of the reasons that open source commercial OS kernels are so vital.

• Access to the massive, arcane, nearly unstructured, non-human-readable Windows Registry, which was to be obsolete by now, remains the only resource a Windows attacker needs to analyze and control a Windows system.

• Another trick that attackers learned from Microsoft is that Registry entries can be made read-only even to the Administrator, so you can find an exploit and be blocked from disarming it.

• Malicious code or data can be concealed in NTFS files' secondary streams. These are similar to HFS forks, but so few would think to look at these.

• One of the strongest tools that Microsoft has to protect users from malware is Access Control Lists (ACLs), but standard tools make ACLs difficult to employ, so most opt for NTFS's inadequate standard access rights.

Why this can't happen under OS X:

• OS X has no user account with privileges exceeding root.

• Maximum privilege is extended only to descendants of process ID 1 (init or Darwin's launchd), a role that is rarely used and closely scrutinized.

• Unlike services.exe, launchd executes daemons and scheduled commands in a shell that's subject to login scripts, environment variables, resource limits, auditing and all security features of Darwin/OS X.

• Apple's daemons have man pages, and third parties are duty-bound to provide the same. Admins also expect to be able to run daemons, with verbose reporting, in a shell for testing.

• OS X Man pages document daemons' file dependencies, so administrators can easily rework file permissions to match daemons' reduced privileges.

• Launchd can tripwire directories so that if they're altered unexpectedly, launchd triggers a response.

• If an attacker takes over a local or remote console, any effort to install software or alter significant system settings cannot proceed without entering the administrator's user name and password, even if the console is already logged in as a privileged user. In other words, even having privileges doesn't ensure that even an inside hacker can arrange to keep them.

• OS X has a single console and a single system log, both in plain text.

• OS X's nearest equivalent to the Registry is Netinfo, but this requires authentication for modification. In later releases of OS X, it is fairly sparse.

• Applications have their own per-user and system-wide properties files, private Registries if you like, stored in human-readable files in standard locations.

• Every installed file is traceable to a bill of materials that can verify that the file is meant to exist, and that it and all of its dependencies match their original checksums. Mac users, back up and protect your Receipts folder!

• The directories used to hold OS X's privileged system executables are sacred. Anything new that pops up there is immediately suspect.

• OS X does not require that a user be logged in as an administrator to install software. The user or someone aiding the install needs to know the name and password of a local administrative user to complete the install. On a network, most software is installed using Remote Desktop, an inexpensive Systems Management Server-like console.

• The UNIX/POSIX API, standard command-line tools and open source tools leave malware unable to hide from a competent OS X administrator. It takes a new UNIX programmer longer to choose an editor than it does to write a console app that walks the process tree listing privileged processes. Finding the owners of open TCP/UDP ports or open files is similarly trivial. The "system" is not opaque.

• Basic OS X features can be put to use to make life miserable for malware. For example, Windows' hackable restore points are done better by OS X's ability to create encrypted, read-only disk images. They're simpler than archives, and you can mount them as volumes anywhere in your file hierarchy.

• Likewise, OS X Server will image any Mac client or server's local drives and maintain safe copies that can be used not only for restoration, but which can be booted from to guarantee that there's no trace of infection.

• When erase-and-reinstall is the only way to be sure, OS X Server automates it. It can safely capture the affected Mac's active drives before having that Mac boot from the fresh install image.

So, after all this, do I have enough to judge Windows inherently more vulnerable to severe malware than OS X? I do. ...

-- by Tom Jager at [http://weblog.infoworld.com/...s_inhe.html] - click to read the whole article.

* The term 'virus' used here relates to malicious software being installed on your system without your knowledge. There is some malicious software (that I am aware of) on macs, and there's no reason why anyone couldn't just write some malicious code, however the secure unix foundation of mac os x and all of it's security features prevent malicious code from being executed without your explicit consent in 99% of cases and if a virus does get running it can't do anything significant without knowing an admin username and password and even then without tipping off the numerous checks and balances that something is awry.

Easily update any element's inner html with an ajax get request. Simple get request

$('div_files').load('getfiles.php');

What it does is get the content of getfiles.php and uses it as the innerHtml for the div with id

'div_files'

Slightly more complex get request

var myHTMLRequest = new Request.HTML({url:'getfiles.php', update:'div_files'}).get({'user_id': 25});

In this get request, like the simple one you specify the location of the server side script, which happens to be in the same directory, and you specify the element who's innerHtml you want to update. After the

.get

you send a variable to the server, in this case

user_id

with the value 25. Note: In the php file you'll need to use a

$_GET['user_id']

instead of

$_POST

I stumbled over this when I was building the CCMCP Library app but I suppose history's due to repeat itself. The problem is this: downloading a file from flex just doesn't work; A dialogue pops up, you choose a place to save the file, but when you hit save no file gets downloaded. If you're sure the url is correct and you haven't made any syntax errors, then the most likely cause is that you've declared the

'fileRef'

variable within the

'download();'

function. The following code will work.

private var fileRef:FileReference = new FileReference();
 
public function download():void
{
fileRef.download(new URLRequest('http://web-site/file-name'), 'simple filename');
}

The problem's also documented at Adobe and Lynch Consulting

Pretty much everyone that uses the internet knows about it, and according to Adobe 99%+ of browsers have it installed. Flash is a browser plugin that lets you view flash content, everything from games, to animation, video and more. Adobe Flex builder is an IDE(Integrated Development Environment) for flash. Where using Adobe Flash(software for making flash content) is foreign to most programmers because it's set up for animation and uses an approach based on frames, Flex Builder was designed for programmers. It lets you build RIAs(Rich Internet Applications) with the richness of flash, with the tools you need like code hinting/highlighting, debugging, and a set of usable, flexible controls. Flex uses Actionscript--the Flash programming language, along with MXML a simple xml schemed language used for the layout of your apps. Flex builder also has a design view that lets you visually arrange and edit the properties of the controls in your application. To use Flex 3 you can get Flex 3 Builder from Adobe or download the open source Flex 3 SDK(Software Development Kit) and use it with your IDE of choice. Flex Builder 3 and FlexBuilder 3 Pro have some extra features that the SDK doesn't, you can see the differences here.

Since this is my first post about computer programming I feel like I should start with the basics. There are many different combinations of servers, databases, languages and frameworks that can essentially accomplish the same thing, in sometimes different ways, usually with more or less features and benefits. Let's start with html. Html is the skeleton, it's responsible for the structure of a web page. Most programmers these days use a form of html called xhtml, which adds the clean orderly feel of xml form, it's more standards compliant and eliminates a lot of errors associated with cross-browser development. You then have css, which styles the html. css is responsible for the layout visually; presentation. These two languages are all you need to create a static page. Now when you get into sites that deliver changing content like blogs, message boards, or online stores, information needs to be dynamically pulled from a database. One of the most versatile and open source databases out there is mysql. In order to communicate with the database a language called php is used. Php is really what makes dynamic sites dynamic. An extremely versatile language used on both small scale; communicating with databases, conditional statements, variables, and functions inter-spliced into web sites, to full scale object oriented programming used in heavy online applications. Finally there's Javascript, a seriously under used and overlooked language that's been around for a long time but only gained popularity in the last few years as the XMLHttpRequest began receiving attention. Javascript is the layer that brings a web page to life, it lets you interact with the html and css of a page without having to reload the page. Ajax, is the name given to the use of the XMLHttpRequest in javascript and it's surrounding functions and effects. It allows a user to interact with the server, like getting information from a database—usually done by communicating with external server-side php files that serve as a go between the javascript and the database, adding a refreshing level of interaction to web sites and applications. A web site is really a set of instructions. All the languages and code don't actually do anything until someone opens their browser and points to a web page thus executing the code. First the web server(where the site is stored) interprets the php—if there is any, sending the resulting html, css, and javascript to your browser which is then responsible for reading through the code and generating the web site. There are many different browsers out there, most of which generate a web page slightly differently. Due to the lack of internet language standards over the years and many items which can be interpreted in different ways, different browsers tend to implement those features in different ways. The most infamous case of this inconsistency is Internet Explorer which instead of following the standards in many cases has gone as far as to develop proprietary tags and hacks just to accommodate their blatantly incorrect interpretation of the various languages. I won't get into the shady ethics of exploiting their leading browser market share (due to being packaged and integrated with windows) to create a situation where appealing to the masses(as a programmer) means having to completely redesign a website to work with their ridiculous browser engine, but business is business. Cross platform is another issue that needs attention as operating systems come with different fonts, use different file types and plugins. These issues can break layout and make an RIA dysfunctional or not work at all. A framework is simply a library of built in functions, classes, and structures that allow a programmer access to higher level functions with far less code as well as simplifying grammar and taking care of security and cross browser compatibility. I'll go into more detail in the future.