Windows Longhorn

[TimP]

Any thoughts/comments/opinions on Microsoft's next major release of Windows? I'll jump in with some of my own thoughts once this thread gets going. For those living under a rock, you can find out more about Longhorn here: http://msdn.microsoft.com/Longhorn

[pixels]

my friend had the alpha

meh
yippe?

[hammocksleeper]

Awesome. I don't feel like reading all that techinical shit so if someone could tell me the major changes, etc. I'd be much obliged.

[TimP]

Awesome. I don't feel like reading all that techinical shit so if someone could tell me the major changes, etc. I'd be much obliged.New graphics engine (code-named "Avalon" is replacing GDI), new storage system (code-named "WinFS" is replacing file storage as we know it), and new communcations engine (code-named "Indigo"). The interface will be vector drawn and powered by a graphics card. This is quite a change considering that every version of Windows including XP and Server 2003 have used bitmapped graphics. There are way too many features to list, but Windows Longhorn is esentially a new operation system, not just an upgrade/patch of the previous version. Longhorn is also being built to fully integrate with the next major release of SQL Server (code-named "Yukon") and the Visual Studio .NET (code-named "Whidbey").

[Duddits]

Soooo.... how long would you estimate it'd take to download that sucka off of KaZaA on a 56k assuming it doesn't get interrupted?

[hammocksleeper]

lmao ^^

Tell me about this new "WinFS" thing, when you say it is a new system of file storage, do you mean it replaces FAT32 and all the other FAT-type systems and is something completely different?

[TimP]

It's replacing the "c:\program files\etc" style paths in favor of a database design. Data will be stored in databases by type, for example a Contacts database. Paths will still be available for legacy apps, but the database style storage is the encouraged type of storage. I've heard that you'll be able to search your entire hard drive for a file in several seconds as opposed to minutes like it is now. I'm not 100% sure on whether or not this affects physical hard drive formats, though.

[Dark_Magneto]

I've been hearing something about Microsoft cooperating with FBI and giving them keys that grant backdoor access to the PC the OS is installed on.

[TimP]

I also heard that Elvis is still alive.

[Duddits]

He is?

I would have that new memroy thing, as I have been scanning my HD for Spyware for at least 20 minutes by now, and it isn't done yet. I only have 12 Gigs of stuff. That isn't too much, is it? (rhetorical question)

[Exedore]

I doubt that I'll even use Longhorn even when it comes out in a few years. Most of it is being coded in C#, which isn't the best programming language to begin with. Also, it's just going to have more bells and whistles to get stupid people to buy it, thinking that it's easier to use or more powerful. I'd rather not have my operating system take up over 150 MB of my physical memory (I managed to get WinXP down to about 70MB).

About the only improvement is that the user interface will have hardware acceleration, like OS X does for Macs currently. But then again, that's just more incentive for them to add more "bloat" to the product. As for the entire "faster searches via SQL", that's nothing that couldn't be done now without integrating it into the OS.

</rant>

[Whiteknight]

He is?

I would have that new memroy thing, as I have been scanning my HD for Spyware for at least 20 minutes by now, and it isn't done yet. I only have 12 Gigs of stuff. That isn't too much, is it? (rhetorical question)
Erm, that's it? I have more than that in music alone... maybe a bit too much music on my part, eh?

Vector drawn, eh? That's going to be pretty hard, or at least I think so. Still, windows will be able to resize things without distortion though.

[hammocksleeper]

I have been scanning my HD for Spyware for at least 20 minutes by now, and it isn't done yet. I only have 12 Gigs of stuff. That isn't too much, is it? (rhetorical question)Next time you backup all your shit, reformat your HD and make a small separate partition for all your Windows and system files and internet browser and internet programs. Put the other stuff on the big one. Then when you pick up spyware it will only be saved on the small partition, which will scan much faster. :)

[TimP]

Most of it is being coded in C#, which isn't the best programming language to begin with.Right now Longhorn, specifically Avalon, is about 50/50 managed code (C#) and unmanaged code (ASM, C, C++, etc.) Like it or not, the trend is towards managed code. Many classes in the .NET Framework itself were written in managed C#. When Longhorn is released, the performance differences between the managed and unmanaged will be hardly noticeable. It's all about preference. Do you want memory leaks and unsafe code in unmanaged code or do you want a slight performance decrease in managed code? One of the plagues of early Longhorn betas was a memory leak in the side bar. The culprit? Unmanaged code.

Also, it's just going to have more bells and whistles to get stupid people to buy it, thinking that it's easier to use or more powerful. I'd rather not have my operating system take up over 150 MB of my physical memory (I managed to get WinXP down to about 70MB).Sure, people are going to buy it for the visuals, but that's also true with OS X and OS X and Longhorn both have a lot of improvements under the hood that people don't realize. You will be able to turn off most of the eye candy and get it down to an XP or Win 2000 look.

About the only improvement is that the user interface will have hardware acceleration, like OS X does for Macs currently. But then again, that's just more incentive for them to add more "bloat" to the product.3D acceleration is not the only new thing in Longhorn. It's moving away from bitmapped graphics and moving towards vectored graphics and support for the new array of high DPI monitors and flat screens. It's also about native 3D support in your Windows apps to take them to a new level. That alone would be quite an upgrade for Windows, but that only covers 25% of Longhorn. You're missing WinFS, Indigo, and Fundamentals. These three are the hardest to explain without a lot of people getting a puzzled look on their face, so they're not talked about as much.

As for the entire "faster searches via SQL", that's nothing that couldn't be done now without integrating it into the OS.</rant>In theory, they could just keep adding more and more features to a nearly five year old operating system, but it would "bloat the product" as you say. You can't simply convert Win XP to a WinFS style file system. It's going to take them two years to add it to Longhorn, so it's pretty substantial.

[WeekendLazyness]

Next time you backup all your shit, reformat your HD and make a small separate partition for all your Windows and system files and internet browser and internet programs. Put the other stuff on the big one. Then when you pick up spyware it will only be saved on the small partition, which will scan much faster. :)
I'd try defragging first. :)


I'm waiting for XAML, sounds fun. Will Longhorn be 64-bit?

[TimP]

I heard that they'll be offering two versions (32-bit and 64-bit) like Windows XP.

[WeekendLazyness]

I figured. It's funny how Intel had to reverse engineer AMD64.

[Exedore]

Right now Longhorn, specifically Avalon, is about 50/50 managed code (C#) and unmanaged code (ASM, C, C++, etc.) Like it or not, the trend is towards managed code. Many classes in the .NET Framework itself were written in managed C#. When Longhorn is released, the performance differences between the managed and unmanaged will be hardly noticeable. It's all about preference. Do you want memory leaks and unsafe code in unmanaged code or do you want a slight performance decrease in managed code? One of the plagues of early Longhorn betas was a memory leak in the side bar. The culprit? Unmanaged code.

More like, "The culprit? Bad programming in C/C++." It's not too terribly hard to make sure that malloc/new'ed memory is free/delete'ed and use a debugger to find leaks. Important components should be written in unmanaged code by competant programmers so that the OS doesn't devour system resources instead of allocating them to applications.

But I guess that concept is a little too hard for Microsoft. Just like bounds checking arrays on network applications is for losers... </sarcasm>

Sure, people are going to buy it for the visuals, but that's also true with OS X and OS X and Longhorn both have a lot of improvements under the hood that people don't realize. You will be able to turn off most of the eye candy and get it down to an XP or Win 2000 look.

Everyone I know that is running OS X bought it because, frankly, OS 9 sucked, especially compared to OS 10.2 (Jaguar) and 10.3 (Panther). But then again, most people I know are CompSci's or CompE's.

I realize that I can turn off the eye candy, but what's more annoying is the underlying services, etc, that most people don't even realize exist. Why is there a service in XP to handle smart cards automatically enabled by default? And then there's the ever more complicated encoding of registry keys so that no one can figure what they're for.

You're missing WinFS, Indigo, and Fundamentals. These three are the hardest to explain without a lot of people getting a puzzled look on their face, so they're not talked about as much.

*sigh* These are the features I may actually care about, If I knew what they were... You shouldn't worry too much, as simply telling people how to implement compatability modes in XP bewilders enough people.

In theory, they could just keep adding more and more features to a nearly five year old operating system, but it would "bloat the product" as you say. You can't simply convert Win XP to a WinFS style file system. It's going to take them two years to add it to Longhorn, so it's pretty substantial.

My point about bloat is that something which isn't very useful at all is being added into the operating system's core components, slowing them down for a miniscule benefit. If, instead, the feature was added as an option on top of the core, but able to be disabled if not needed, it would be a far better improvement. Microsoft has a tendency to assume that something will be great for everyone and then not caring about the fact that it's hard to get rid of if someone doesn't want it.


I figured. It's funny how Intel had to reverse engineer AMD64.
Actually, that's not funny at all. It's done by AMD and most other competing chip manufacturers as well, or any competators for that matter. Whenever the competator comes out with a new design, a company will buy some samples and reverse engineer them to find out how they did everything.

[TimP]

I did have a nice reply typed out and ready to go, but a timeout on the Warboards server caused my whole message to be lost.

Anyways, I'll sum up what I was going to say. Managed code is good because no one writes perfect code and it saves a lot of time not having to worry about memory leaks. Obviously the essential core files need to be written in unmanaged code, but I think the trend towards managed code is good.

I also know people who are looking forward to Longhorn for the features, not the eye candy. It all depends on who you talk to. Joe Blow may be anticipating the eye candy, but serious computer users are also interested in the other pillars of Longhorn. That applies for any OS. I'm sure people were looking forward to sliding windows and bouncing icons in OS X, too.

Trying to put WinFS into XP is like trying to put on a coat that doesn't fit. Win XP was never meant to accomodate WinFS and trying to jam it in there would cause a bloated system. First of all you have to support the existing file system and add a whole second file system on top of that. That's not what I would want. Longhorn is going to have native WinFS support so it will be a much smoother experience.

More about the pillars of Longhorn: http://msdn.microsoft.com/Longhorn/understanding/pillars/default.aspx

It's funny how Intel had to reverse engineer AMD64.And it's funny how an AMD fanboy uses an Intel chip. ;)

[WeekendLazyness]

Actually, that's not funny at all. It's done by AMD and most other competing chip manufacturers as well, or any competators for that matter. Whenever the competator comes out with a new design, a company will buy some samples and reverse engineer them to find out how they did everything.
I meant ironic, since Intel usually sets the standards.

And it's funny how an AMD fanboy uses an Intel chip. ;)
Who said I was a fanboy? I love my Intel chip and know more about the P4 than the Athlon.

[Exedore]

I did have a nice reply typed out and ready to go, but a timeout on the Warboards server caused my whole message to be lost.

I've had that happen to me before. That's why I try to remember to hold large posts in a temp file or in the clipboard until they're entered into the server.

Trying to put WinFS into XP is like trying to put on a coat that doesn't fit. Win XP was never meant to accomodate WinFS and trying to jam it in there would cause a bloated system. First of all you have to support the existing file system and add a whole second file system on top of that. That's not what I would want. Longhorn is going to have native WinFS support so it will be a much smoother experience.

More about the pillars of Longhorn: http://msdn.microsoft.com/Longhorn/understanding/pillars/default.aspx


Wow, it's amazing how worthless WinFS, Indigo, Avalon, and Fundementals are, now that I know what they are.

WinFS is just removing the Hierarchical Directory structure that most people are used to and transforming it into an SQL database. The physical file system, which I thought you were referring to initially, will still remain mostly the same. It's basically taking a file cabinent, emptying it out onto a desk, but having a slave to find things for you. Instead of knowing where something is and quickly finding it (although it requires opening some drawers), you have to expect the query (slave) will find what you want. And the best part is, it only works on a few standard formats and Microsoft proprietary ones. Everything else will still be searched for by an extension like we do now.

And just so you know, this can be easily implemented over top of the existing windows file system and it would be almost as fast.


Fundementals (which encompasses Indigo and Avalon) is an extension of C# or Visual Basic into a scripting language. It's basically enhanced Visual Basic script. Avalon is just the windowing side of it (as opposed to the scripting aspect) and Indigo is their "improved" RPC protocol. All it boils down to is a marketing gimic to trick people into developing programs that can only run on Windows machines.


Thank you for showing me how much Longhorn sucks. I shall leave you with a funny quote from the Fundementals description: In addition, Longhorn is the first operating system designed from the ground up with security and trustworthy computing at the core.They said something similar about Windows 2003, which was hit a few months later with the RPC exploits, such as blaster. And now their RPC is becoming a "user-friendly" scripting language? This only begs to be exploited, seeing as how simple javascript can wreak havoc with IE.

[WeekendLazyness]

WinFS is just removing the Hierarchical Directory structure that most people are used to and transforming it into an SQL database. The physical file system, which I thought you were referring to initially, will still remain mostly the same. It's basically taking a file cabinent, emptying it out onto a desk, but having a slave to find things for you. Instead of knowing where something is and quickly finding it (although it requires opening some drawers), you have to expect the query (slave) will find what you want. And the best part is, it only works on a few standard formats and Microsoft proprietary ones. Everything else will still be searched for by an extension like we do now.
I see it as taking a file cabinet, and making an index of the contents for much faster searching. I also think you are too negative.

[TimP]

You can't possibly grasp the full extent of Longhorn just by reading a few paragraphs. Take a look at some of the videos and interviews if you really want to see this technology used effectively. WinFS will be expandable with the use of schemas, so it's as expandable as the developers/users want to make it. Comparing WinFS to the current file system is like comparing the efficiency of a database (MySQL, MS SQL, Oracle) to the efficiency of thousands of random text files. As we've seen on the web, the database wins. Regardless of whether you like it or think it's necessary, that's what Microsoft is doing. I can see you didn't touch on the guts Indigo at all, which to me is one of the most interesting things in Longhorn. I can also tell you either didn't read or understand the articles with your quick synopsis at the end. Fundamentals is neither an extended scripting language nor the combination of Indigo and Avalon. Indigo is NOT just an improved RFC protocol. I honestly do not have the time to explain all of this because I would be doing an inservice to the people at Microsoft (they know best) and exhausting myself by typing pages and pages of information. And as for your poke at Windows security, the latest incarnations of Windows Server/IIS beat Linux in security, so I know what I'm sticking with.

[Exedore]

You can't possibly grasp the full extent of Longhorn just by reading a few paragraphs. Take a look at some of the videos and interviews if you really want to see this technology used effectively.

Perhaps I will when I have more free time. And maybe I'll get to laugh at Steve Balmer...

WinFS will be expandable with the use of schemas, so it's as expandable as the developers/users want to make it. Comparing WinFS to the current file system is like comparing the efficiency of a database (MySQL, MS SQL, Oracle) to the efficiency of thousands of random text files. As we've seen on the web, the database wins.

After looking closer at the architecture diagram (http://download.microsoft.com/download/a/2/f/a2fc47d2-8bdf-4977-8364-1f38b893dba5/lharch_pdc2003.png) (warning - very large PNG), it is pretty clear that WinFS is another higher level abstraction from the base file system of the disk, which is still NTFS. WinFS is mostly just an expansion on the "My<some type of document>" scheme and MIME types. Instead of having a folder pointed to by MyDocuments, you have a listing a where all the files are, when you used them, etc. It also boasts improved file type association that uses file headers instead of extensions to group things. But like I said, it's not really necessary. Using databases to store all this won't help me find a file significantly faster than what I can already do.

Regardless of whether you like it or think it's necessary, that's what Microsoft is doing.
I realize that, I'm just saying that I think it's not a good decision. In case you haven't guessed, I will most likely not being using Longhorn when it eventually is released.

I can see you didn't touch on the guts Indigo at all, which to me is one of the most interesting things in Longhorn. I can also tell you either didn't read or understand the articles with your quick synopsis at the end. Fundamentals is neither an extended scripting language nor the combination of Indigo and Avalon. Indigo is NOT just an improved RFC protocol. I honestly do not have the time to explain all of this because I would be doing an inservice to the people at Microsoft (they know best) and exhausting myself by typing pages and pages of information.

I didn't notice that the title of each pillar was also a hyperlink originally, so that was based off of the one example article. From looking at it more, Indigo is basically the network portion of Fundementals, and Avalon is the User Interface portion. The main goal of fundementals, avalon, and indigo is to make it so that people who don't have a lot of programming experience can make quick and dirty applications that can potentially have built-in CVS and automatic client downloads/installations. Basically making Visual Basic/C# applications easier to distribute on windows systems.

And as for your poke at Windows security, the latest incarnations of Windows Server/IIS beat Linux in security, so I know what I'm sticking with.

I'll have to dig up the article about Microsoft using a Linux webserver to host the website about their new Windows web server because the Windows one kept crashing. As far as I know, the only major problems with Linux that I've seen is the SSL bug/exploit that was fixed within days of its discovery/release and a few exploits of the map command by users with local accounts to gain root privileges.

I see it as taking a file cabinet, and making an index of the contents for much faster searching. I also think you are too negative.

That was probably a bad example, seeing as an SQL database is basically a file cabinent. It's hard to relate trees to filing papers...

And I do realize that I'm being negative. I just hate unnecessary features in software, which each successive version of windows has more of.

[TimP]

Improved performance and faster file finding is exactly what they're trying to achieve with WinFS. What I mean by it will be faster to find your files is if you use the Search app in Win XP. Right now on a drive with tens of thousands of files, it takes a painfully long time to search the drive. WinFS will remedy this problem. I'm also curious about the reasons for your disliking of managed code, if you'd care to elaborate.

The main goal of fundementals, avalon, and indigo is to make it so that people who don't have a lot of programming experience can make quick and dirty applications
It's interesting how you see RAD as "quick and dirty programming". In the current world, programmers don't have time to reinvent the wheel on every project. Do you consider MFC "quick and dirty programming" because it takes a lot of the work out of Windows programming compared to C? Faster development does not always mean "quick and dirty".

Actually, your "story" about Microsoft running their site on a Linux server is totally bogus. The reason that it may look like MS is using Linux servers is because they use Akamai traffic distribution to decrease the chances of their site getting knocked out by a DOS attack. As we saw with the MyDoom virus, Microsoft's site was stable as a rock, while SCO's site went under almost instantly.

[Exedore]

Improved performance and faster file finding is exactly what they're trying to achieve with WinFS. What I mean by it will be faster to find your files is if you use the Search app in Win XP. Right now on a drive with tens of thousands of files, it takes a painfully long time to search the drive. WinFS will remedy this problem.

I can do a search for about any file on my hard-drive with the WindowsXP search and have a result in under 15 seconds. For searching about 70GB of data, that's pretty good. A 5 or 10 second difference by winFS's use of SQL isn't really much of a benefit for the extreme overhead that it would need.

I'm also curious about the reasons for your disliking of managed code, if you'd care to elaborate.

I don't hate managed code for the fact that it's managed. Automatic "garbage collection" is nice at times. But if you're writing something that needs to be fast and efficient, like an operating system, the extra overhread of managed code is a detrimental thing.

It's interesting how you see RAD as "quick and dirty programming". In the current world, programmers don't have time to reinvent the wheel on every project. Do you consider MFC "quick and dirty programming" because it takes a lot of the work out of Windows programming compared to C? Faster development does not always mean "quick and dirty".

If I wanted to make something sizable to sell that had to be quick, efficient, and solid, I would do it in C/C++. If I needed some one-time application for non-computer literate people to analyze data, I'd probably use vB because I can get a quick user interface made. Sure, it would be slower, but since it won't be used very often, the trade-off of application speed and development time isn't worth it.

Actually, your "story" about Microsoft running their site on a Linux server is totally bogus. The reason that it may look like MS is using Linux servers is because they use Akamai traffic distribution to decrease the chances of their site getting knocked out by a DOS attack. As we saw with the MyDoom virus, Microsoft's site was stable as a rock, while SCO's site went under almost instantly.

It wasn't their whole site, it was just the site for a new webserver application they were developing that, if you believe microsoft marketing, was going to be, "the best, most secure webserver ever..." I'll have to see if I can find that story.

[WeekendLazyness]

I can do a search for about any file on my hard-drive with the WindowsXP search and have a result in under 15 seconds. For searching about 70GB of data, that's pretty good. A 5 or 10 second difference by winFS's use of SQL isn't really much of a benefit for the extreme overhead that it would need.
Ha! Searching the whole drive, not some file in My Documents? I think not.


I don't hate managed code for the fact that it's managed. Automatic "garbage collection" is nice at times. But if you're writing something that needs to be fast and efficient, like an operating system, the extra overhread of managed code is a detrimental thing.
I do love my operating systems full of buffer overflows.


It wasn't their whole site, it was just the site for a new webserver application they were developing that, if you believe microsoft marketing, was going to be, "the best, most secure webserver ever..." I'll have to see if I can find that story.
Microsoft would never use a Linux server. They outsourced their traffic handling to a company that happaned to use Linux, as Tim explained.

[TimP]

I'm also a bit skeptical on searching through every file on your 70GB HD in 15 seconds, unless you have very few files on your hard drive. 5 or 10 years ago I may have agreed with you about managed code. The fact of the matter is that with today's processing power, you'd be hard pressed to point out unmanaged code from managed code just by running a program. How often are you writing your own operating system? Now obviously you wouldn't try writing a game engine with the complexity of Unreal Tournament 2004 in managed code, but I think you'll start to see more main stream programs switch to managed code. Microsoft is starting to use C# on Microsoft Office development and on their other projects. I read somewhere that C# (and the rest of the .NET languages) run at 80% or 85% of the speed of high quality, unmanaged C++ code.

[marsius]

I will certainly purchase a PC with Longhorn once it is released. I like all of the features (or bloat, as many refer to it). It's looking like it will be released before I head off to law school so I will purchase a new notebook right before I take off. I personally love funky features. Give me beautiful graphics. Give me stuff that allows me to divert just a little more thought from the functioning of my PC. There's a reason that I'm not a CS major: I just don't care. I'm not a gamer either, so I really don't mind if it eats up resources.

[Exedore]

Ha! Searching the whole drive, not some file in My Documents? I think not.
Nope, it was the whole hard drive. Searching for a file in MyDocuments took under a second. In fact, as long as I limit my search to practically any sub-directory of my hard disk, the searches take about a second. Granted, a lot of my information consists of ~250MB anime episodes, but there is still a myriad of smaller files floating around all over the system.

I don't hate managed code for the fact that it's managed. Automatic "garbage collection" is nice at times. But if you're writing something that needs to be fast and efficient, like an operating system, the extra overhread of managed code is a detrimental thing. I do love my operating systems full of buffer overflows.

Buffer overflows can happen in managed code too, you just have to try and cause them. Stack overflows are one way, or you can also create an exceedingly large array. But those mostly just cause crashes. The main way to cause any buffer overflow is find an exploit in the memory manager (which at some point had to be written in unmanaged code) and make a call in the managed code to exploit that. Most good unmanaged code will do bounds checking of some sort in order to avoid buffer overflows. In fact, many larger applications have their own memory managers that are optimized for that particular program.

Microsoft would never use a Linux server. They outsourced their traffic handling to a company that happaned to use Linux, as Tim explained.

Just like Microsoft would never use a Mac, right?

[Edgewize]

Nope, it was the whole hard drive. Searching for a file in MyDocuments took under a second. In fact, as long as I limit my search to practically any sub-directory of my hard disk, the searches take about a second. Granted, a lot of my information consists of ~250MB anime episodes, but there is still a myriad of smaller files floating around all over the system. Searching can be really fast if you're willing to give up disk space for a pre-computed search tree. That's what the Microsoft Office "Fast Find" feature has done since Office 97, and I bet that something similar is built into Windows XP (I still run 2000).

I wouldn't be surprised if the directory indexes in Longhorn suck up over 5% of your disk space. But with today's HD capacities, I guess it's a fair trade.

Buffer overflows can happen in managed code too, you just have to try and cause them. Stack overflows are one way, or you can also create an exceedingly large array. But those mostly just cause crashes. The main way to cause any buffer overflow is find an exploit in the memory manager (which at some point had to be written in unmanaged code) and make a call in the managed code to exploit that. Ideally, the memory manager is written in mostly managed code, with just a very small unmanaged core. If you can prove that the core is free of exploits, then the whole system is secure. Microsoft is big on security right now, so I'm sure they've pounded the living hell out of their .NET memory manager by now. I'd trust it.

[WeekendLazyness]

Just like Microsoft would never use a Mac, right?
Actually, they have a division that uses just Macs. That division makes software for the Mac.

[hammocksleeper]

Searching can be really fast if you're willing to give up disk space for a pre-computed search tree. I wouldn't be surprised if the directory indexes in Longhorn suck up over 5% of your disk space.
Well, that's what a database will do, isn't it? The old Dos tree style is probably as simple as you can get. Anything more complex has to take up more space.

[Exedore]

Actually, they have a division that uses just Macs. That division makes software for the Mac.

I was wondering if anyone would pick up on that. A lot people made a fuss about Microsoft buying some G5's a few months back, not realizing that Office and Internet Explorer, among other things, have been ported to macs.

[d00d]

I'm not buying anything with a dick as a logo... =_=