With SDL, you can do 2D, 3D (via OpenGL), Sound, Input, and basic video overlay. It supports well over a dozen platforms, including consoles.
GPU-accelerated video decoding isn't supported/exported, but that's not part of DirectX. SDL even has a Networking layer too, but it's not part of the core. (Actually DirectPlay is deprecated, and its replacement isn't part of DirectX either)
I was using BINS (http://bins.sautret.org/) for a while -- I even sent in several patches to speed it up -- but in the end a static set of pages simply got too large to manage manually. And that was only 4000 or so images.:)
That said, BINS is nice for small, fire-and-forget static galleries. IT's just not a management solution.
It's primary purpose is to be a photographer's main image repository rather than "post a bunch of images online and blog about it" As such, it lacks social networking features (beyond ratings) but it scales up to ginormous repository sizes. My personal site has over 30K images (in over 100GB).
It supports multiple image versions, extensive tagging, bulk updates, and has fancy search, import, and export features. It's built on top of PostgreSQL, making extensive use of stored procedures and triggers, not to mention the usual ACID features.
This is a shameless self-plug though -- I stumbled across PO a couple of years ago and ended up contributing so much back that the original author handed the reigns to me. I have a huge laundry list of features to add, mostly driven by real-world needs.
The problem with spec.org is that they report vendor results from entire system tests rather than "keep everything the same and switch out as few components as possible". In other words, use the same OS, same CPU, same RAM, same compiler, ideally the same binaries, etc..
There's also a historical tendency to cheat as much as possible through use of esoteric compiler flags that would have real world programs crashing left and right, if they even compiled at all. This is especially true of SpecFP.
Finally, there doesn't seem to be any indication of 32-bit or 64-bit operation in the table, but as the random sampling I checked out all seemed to be running on WinXP, I'd wager these tests were 32-bit only. Even the handful of SpecInt tests I found running on 64-bit platforms seemed to be building the code in 32-bit mode.
I'm still waiting for pure 64-bit benchmarks along the lines of "how long will it take to compile a large, complicated source tree, like, say, the Linux kernel?" -- it's something I easily do a dozen times a day, being in the embedded systems biz and all.
All 64-bit benchmarks I've seen so far are either desktop-type apps or are comparing AMD64 to P4-Prescott, which isn't really relevant any more.
Those Anandtech benchmarks are still running 32-bit code on Vista-64, and still just desktop-type applications. If anything, they're slower than Vista-32 would be. (Well, with the exception of the 3D Rendering tests...)
Still, it's a more useful benchmark set than you usually see.
There's no arguing that the Core2 parts are much faster than the current RevF AMD64 parts when running SSE-optimized code in 32-bit mode. My point is that the "Desktop workload" that these guys keep benchmarking ad nauseum isn't the only workload people care about, myself included.
The vast majority of the stuff I do simply doesn't (or can't) take advantage of MMX/SSE, so benchmarks for off-the-shelf desktop apps that are heavily weighted towards SSE performance don't tell me what I need to know.
I don't care about games. I rarely encode MP3s. I don't even own MS Office or Photoshop -- All image manipulation I do revolves around dcraw, ImageMagick, and other completely-scriptable tools.
Likewise, I don't care about 32-bit performance, SSE or otherwise, because unless something drastically changes, 64-bit mode on an AMD processor gains me far more than the slight improvements the Core2 parts demonstrate on 32-bit code.
What little benchmarking I found was that the AMD64s spanked the Prescotts with 64-bit code. The P-M, Banias, and Core parts didn't support 64-bit mode, but the Core2 does. I simply want to know how it compares, but I have yet to see a (repeatable, non-anectdotal) comparison with the Core2 running pure 64-bit code.
Of course OfficeXP uses SSE -- it makes heavy use of the graphics libraries and drivers, which are uber-optimized, even if the rest of OfficeXP is the epitome of unoptimized bloat.
But it's worth mentioning that "Office XP runs 2% faster" is fairly meaningless, because when you're sitting down at the keyboard, 99% of the time Office is sitting there waiting for your input, so that 2% performance increase results in you saving a whopping ten CPU seconds over the course of your workday. Big whoop. (even if you somehow managed to keep Office pounding the CPU continuiously over an eight-hour workday, you'd save a whopping 8.4 minutes!)
I'm more interested in compiler speed, crypto speed, non-photoshop image mangling (using straight integer or compiler-optimized C), simulation runs, testsuites, server performance using PHP, Perl, and Java. You know, things that don't generally lend themselves to vecorization thus rendering MMX/SSE useless.
Native 64-bit support gives me a considerable performance boost (>50% is typical) over 32-bit integer-intensive code on my Turion64 laptop, and I'd love to see if the Core2 parts can match or exceed that.
Perhaps more to the point -- I'm curious about the raw integer performance of the AMD64 vs Core2 parts. A great deal of the extra performance that the Core2 parts demonstrate is due to their single-cycle SSE engines (which the upcoming AMD parts will match), but if your code doesn't use SSE (ie your typical server app) then all of these desktop-type benchmarks are worthless.
I'd also love to see a native 64-bit (integer) benchmark as well, both with and without SSE-enabled tests.
I have to say this was a nice ego boost to come across; you'd be surprised on just how little feedback I get on PO, positive or otherwise. I don't even know how many users there are.:)
In my case -- I needed remote network access, but I also wanted to be in full control of my data. I primarily wanted a full-on repository to hold *everything*, with configurable views for different people (and/or the general public). I didn't want to have to manually generate web galleries and manage all of that independently.
After some casting about, I ended up settling on Photo Organizer. It's fully database-driven (PostgreSQL) and thus scales quite well -- It was designed to be, first and foremost, a photographer's primary image repository. It has the usual assortment of tagging, folders, albums (aka views), is fully multi-user with permissions, etc etc.. it's also web-driven (PHP), so you don't have to be sitting at a single PC to do any work.
So I started using it, and to make a long story short I contributed so much to it that I ended up taking over maintainership, which makes this a bit of a self-plug.
It also supports a full export of all stored metadata, so you have direct control over all of your valuable metadata.
It's not perfect, naturally, and its non-native nature means that fancy UIs just aren't possible, but it's designed to be an image repository, not an image editor...
I was doing this for a couple of years. Unfortunately the C/Dock II only supports PCI, which limits your graphics card choices considerably, but you can get modern low-end PCI cards still, and they're loads better than what my (reflashed) Inspiron 4100 came with (16Mb Radeon M6). Before I ended up replacing the machine altogether, I was using a Radeon 256MB 9250 card, which even gave me usable DX8-class grafix.
My current Acer laptop's eZDock is PCIe based (and even has an expresscard slot) so there's no inherent reason why they couldn't build a unit with a full PCIe slot for an external graphics card.
I wish I could find a link somewhere, but back in the Windows 3.x days, the days where serial mice were common, the days when _Mouse Systems_ actually meant something, the days when mice were ugly bricks, the days before the MS dove bar mouse, I remember seeing a mouse by Genius that had a front-center-mount scroll wheel.
The wheel wasn't clickable as a third button, but the spiel on the box was all about how it would make scrolling that much easier.
So Microsoft didn't invent the wheel mouse, but they did refine it considerably and make it universally usable, thanks to their ability to integrate tightly into the OS. It's so much easier to do that when you control the APIs.
Actually, their disk tests are fundamentally flawed. RAID0 is only good for boosting raw sustained throughput; it has pretty much no effect on access time. If you want a boost in access time, go for RAID1, as you can load-balance reads across two drives.
Furthermore, RAID0+1 is also not really worth it, as it still only gives you the ability to fail one drive, and instead of two logical spindle you only have one to do all of the work. But I suppose of your software is inflexible enough to only be able to operate on one partition, so be it.
I'd like to see some numbers for their boxes loaded up with RAM and high numbers of random I/O operations, which is where the high rotational speed of modern SCSI drives really shine. And this is the access pattern of a dynamic database-driven web site.
And as others have said, it's not the hardware that makes the most difference in these circumstances, it's how the software is set up, and how the site/database is coded.
Hell, I've completely saturated a 100mbps network serving dynamic content via pure Java Servlets, and this was only a dual P3-650. With a RAID5 array of 50G 7200RPM SCSI drives, hardly cutting edge even at the time. Dropping in a RAID1 array of WD120 IDE drives couldn't come anywhere close. But once the working set of data was loaded into RAM, they both performed about the same.
Their IDE raid setup is certianly considerably cheaper though, and that's a tradeoff that most people can easily make.
Microsoft would be providing a common 802.11 MAC implementation. IEEE 802.11 is well-documented fully-open standard that ANYONE can download and implement
If MS made their implemtation with windows-only quirks, they wouldn't interoperate with every single card already out there.
And we're talking several million WiFi devices easily.
Manufacurers would be *more* likely to release specs, because the hardware and thus the programming interface would be much simpler.
These "Soft" WiFi cards still do full frame decoding, MAC matching and whatnot. They are roughly equal in intelligence to the average 10/100 ethernet card.
And in fact, most cards do WEP in the driver anyway.:)
As long as the hardware docs are published (register maps, DMA engine programming, etc) they'll work like a champ with Linux, that is once the host-based-mac stuff is further along.
(See one of my posts above for more details)
- Pizza [who does a lot of wireless driver hacking]
As someone who spends a considerable amount of time these days hacking on WiFi card drivers, Host-based MAC is actualla a VERY good thing.
A good analogy of this is PPP. The current situation is similar to a modem manufacturer embedding PPP in the hardware, which is horribly complex and expensive to implement. It is much simpler and cheaper to let the OS provide the PPP services.
WinModems come in two flavors; host-based controller and host-based signal processing. The latter is pure evil; the hardware is nothing more than a A/D/A converter, and the host CPU has to perform all DSP functions to make it into a modem. The host-based-controllers have real hardware DSPs and whatnot, but they just tell the DSP what to do, essentially replacing an on-board processor+firmware with the driver on the host machine.
WinWiFi (which is really host-based-MAC) is neither. The WinWiFi card would become about as smart as the average ethernet card; ie it would be able to transmit and receive raw 802.11 frames, and then pass them off to the driver which then figures out what to do with them.
A good portion of the wireless cards out there already do this, and nearly all of the new ones will do this. Why? complexity and cost.
802.11 is rather complicated. The MAC must handle a complex state machine; with all sorts of little nuances. Handling transmits/receives, and their acks, association, channel hopping, and then the real doozey: encryption.
WEP sucks. Not just because it's fundamentally broken, but because it takes a bit of oomph to work with, and it's a little complex. And if this is done in hardware, you can't update it to handle newer standards.
Every single one of the 802.11 extensions to replace/augment WEP will require considerably more computation power in hardware; but in fact, most 802.11 (windows) drivers now do WEP on the host, because it has far more computational power to spare with zero additional hardware cost.
This WinWiFi initiative is nothing more than "hey, all of you guys have already written this host-based-MAC stuff (or are going to have to write it anyway) so why not just use the stuff already part of the OS? It's already been extensively tested and that way, you don't need to reinvent the wheel."
It's called shared code, and makes a lot of sense.
I've been banging my head against the wall a lot lately because of buggy firmware in WiFi cards; If they let the host OS do the work instead, these bugs wouldn't exist, because the 802.11 spec is well-documented.
And again, it's not WinWiFi, it's Host-based-MAC. It's a work-in-progress for Linux too. And it is a GoodThing(tm).
1) Ever heard of the _Java Community Process_? nearly everything new to come into Java ThePlatform(tm) came through this. And anyone can participate in the JCP. Anyone. 2) I'll grant you that you need to get a license to implement the language.. but that's primarily there to ensure the quality of the implementations, which have to pass quite a validation process.. 3) Microsoft didn't deviate from the spec *slightly*, they left gaping holes in their implementaion, and included all sorts of non-standard windows-specific stuff that negated the whole reason to use Java to begin with. People tried to use stuff coded to the java spec, and it broke on MS's VM. That's where the lawsuit came from.
If you make chances to the language, it is no longer Java, because the resulting language is different from what everyone else expects it to be.
Nobody can make changes to C, and still call it C and expect it to work anywhere. That's why there is ANSI C, to define what MUST be there for it to be called C. Have you ever tried to get code to compile under multiple compilers on the same platform? Java avoids these headaches because it is very rigidly specified.
And you're missing one very crucial point. C# is just another language, one of *thousands* of other languages. The language itself is remarkably unremarkable, much like Java, actually. There really isn't anything new from a language perspective.
The real power comes from the *platform* as a whole, including the class libraries one has access to. (After all, even C is pretty worthless without #include ) and I'll bet a nickel that 90% of the libs will remain windows-specific because they're being used via COM. Which is completely non-portable, and reduces you to once again doing Windows programming with yet another language. Big Whoop.
Whether the LANGUAGE is open or not is irrelevant. What matters is whether the rest of the system is open. (Aaside from the language and CLR spec, almost none of it is) And MS has an extremely poor track record in this regard with their propensity to embrace, extend, control , punish.
C# is a remarkable improvement to the way you develop Windows applications, but *everything* it does has already been done before; primarily by Java.
(...and freely implemented by anyone? Have you read the license for the CLR stuff? There's a reason that everyone involved in alternate implementations is deliberately avoinding being tainted by MS code)
You're wrong, actually. "Recording your favorite eposide while you're out for dinner" _is_ legal. It doesn't matter what the studio says or not.
Wnder the DMCA, if the studio implemented some kind of technological access control (say, a flag that says "no timeshifting") then recording your favorite episode is still legal -- as long as you don't bypass the access control.
It's the act of bypassing the access control that's illegal under the DMCA, not the actual timeshifting itself. It's a crucial difference. And that's why the general populace doesn't know.
Why is Java on the requirements of the job? Because perhaps it's java that generates the web pages. Perhaps it's java that the servers run on. Perhaps there are java components somewhere.
"Java makes it hard to do easy things and easy to do hard things."
probably about 50% of my development work is in Java, but you don't see any java applets or java code on our web pages.
If I'm going to spend $2000 on a recordable CD/DVD drive, I will want to be able to use it in high-end workstattions. Can you honestly tell me that people author movies and commercials on a PC?
If I'm going to have a couple hundred gigs of SCSI raid-5 storage for my video works in progress, I'm going to want to plug in a SCSI recorder as well. And there's no way I'm going to enable an IDE bus (or hell, install an IDE controller) in a system that has everything else already SCSI.
That said, I'll be very surprised if Pioneer doesn't release a SCSI version of this drive. Hell, they're one of the two companies that makes SCSI DVD-ROM drives. (the other being Toshiba).
Mass market acceptance means they'll have to do an IDE version. But at a $2000 price level, they're not looking for mass market acceptance.
Slashdot Mirror
SimpleDirectMedia Layer. (http://www.libsdl.org/)
With SDL, you can do 2D, 3D (via OpenGL), Sound, Input, and basic video overlay. It supports well over a dozen platforms, including consoles.
GPU-accelerated video decoding isn't supported/exported, but that's not part of DirectX.
SDL even has a Networking layer too, but it's not part of the core. (Actually DirectPlay is deprecated, and its replacement isn't part of DirectX either)
I was using BINS (http://bins.sautret.org/) for a while -- I even sent in several patches to speed it up -- but in the end a static set of pages simply got too large to manage manually. And that was only 4000 or so images. :)
That said, BINS is nice for small, fire-and-forget static galleries. IT's just not a management solution.
http://po.shaftnet.org/
It's primary purpose is to be a photographer's main image repository rather than "post a bunch of images online and blog about it" As such, it lacks social networking features (beyond ratings) but it scales up to ginormous repository sizes. My personal site has over 30K images (in over 100GB).
It supports multiple image versions, extensive tagging, bulk updates, and has fancy search, import, and export features. It's built on top of PostgreSQL, making extensive use of stored procedures and triggers, not to mention the usual ACID features.
This is a shameless self-plug though -- I stumbled across PO a couple of years ago and ended up contributing so much back that the original author handed the reigns to me. I have a huge laundry list of features to add, mostly driven by real-world needs.
The problem with spec.org is that they report vendor results from entire system tests rather than "keep everything the same and switch out as few components as possible". In other words, use the same OS, same CPU, same RAM, same compiler, ideally the same binaries, etc..
There's also a historical tendency to cheat as much as possible through use of esoteric compiler flags that would have real world programs crashing left and right, if they even compiled at all. This is especially true of SpecFP.
Finally, there doesn't seem to be any indication of 32-bit or 64-bit operation in the table, but as the random sampling I checked out all seemed to be running on WinXP, I'd wager these tests were 32-bit only. Even the handful of SpecInt tests I found running on 64-bit platforms seemed to be building the code in 32-bit mode.
I'm still waiting for pure 64-bit benchmarks along the lines of "how long will it take to compile a large, complicated source tree, like, say, the Linux kernel?" -- it's something I easily do a dozen times a day, being in the embedded systems biz and all.
All 64-bit benchmarks I've seen so far are either desktop-type apps or are comparing AMD64 to P4-Prescott, which isn't really relevant any more.
Those Anandtech benchmarks are still running 32-bit code on Vista-64, and still just desktop-type applications. If anything, they're slower than Vista-32 would be. (Well, with the exception of the 3D Rendering tests...)
Still, it's a more useful benchmark set than you usually see.
There's no arguing that the Core2 parts are much faster than the current RevF AMD64 parts when running SSE-optimized code in 32-bit mode. My point is that the "Desktop workload" that these guys keep benchmarking ad nauseum isn't the only workload people care about, myself included.
The vast majority of the stuff I do simply doesn't (or can't) take advantage of MMX/SSE, so benchmarks for off-the-shelf desktop apps that are heavily weighted towards SSE performance don't tell me what I need to know.
I don't care about games. I rarely encode MP3s. I don't even own MS Office or Photoshop -- All image manipulation I do revolves around dcraw, ImageMagick, and other completely-scriptable tools.
Likewise, I don't care about 32-bit performance, SSE or otherwise, because unless something drastically changes, 64-bit mode on an AMD processor gains me far more than the slight improvements the Core2 parts demonstrate on 32-bit code.
What little benchmarking I found was that the AMD64s spanked the Prescotts with 64-bit code. The P-M, Banias, and Core parts didn't support 64-bit mode, but the Core2 does. I simply want to know how it compares, but I have yet to see a (repeatable, non-anectdotal) comparison with the Core2 running pure 64-bit code.
Of course OfficeXP uses SSE -- it makes heavy use of the graphics libraries and drivers, which are uber-optimized, even if the rest of OfficeXP is the epitome of unoptimized bloat.
But it's worth mentioning that "Office XP runs 2% faster" is fairly meaningless, because when you're sitting down at the keyboard, 99% of the time Office is sitting there waiting for your input, so that 2% performance increase results in you saving a whopping ten CPU seconds over the course of your workday. Big whoop. (even if you somehow managed to keep Office pounding the CPU continuiously over an eight-hour workday, you'd save a whopping 8.4 minutes!)
I'm more interested in compiler speed, crypto speed, non-photoshop image mangling (using straight integer or compiler-optimized C), simulation runs, testsuites, server performance using PHP, Perl, and Java. You know, things that don't generally lend themselves to vecorization thus rendering MMX/SSE useless.
Native 64-bit support gives me a considerable performance boost (>50% is typical) over 32-bit integer-intensive code on my Turion64 laptop, and I'd love to see if the Core2 parts can match or exceed that.
Perhaps more to the point -- I'm curious about the raw integer performance of the AMD64 vs Core2 parts. A great deal of the extra performance that the Core2 parts demonstrate is due to their single-cycle SSE engines (which the upcoming AMD parts will match), but if your code doesn't use SSE (ie your typical server app) then all of these desktop-type benchmarks are worthless.
I'd also love to see a native 64-bit (integer) benchmark as well, both with and without SSE-enabled tests.
I have to say this was a nice ego boost to come across; you'd be surprised on just how little feedback I get on PO, positive or otherwise. I don't even know how many users there are. :)
It all depends on what you really want, and need.
In my case -- I needed remote network access, but I also wanted to be in full control of my data. I primarily wanted a full-on repository to hold *everything*, with configurable views for different people (and/or the general public). I didn't want to have to manually generate web galleries and manage all of that independently.
After some casting about, I ended up settling on Photo Organizer. It's fully database-driven (PostgreSQL) and thus scales quite well -- It was designed to be, first and foremost, a photographer's primary image repository. It has the usual assortment of tagging, folders, albums (aka views), is fully multi-user with permissions, etc etc.. it's also web-driven (PHP), so you don't have to be sitting at a single PC to do any work.
So I started using it, and to make a long story short I contributed so much to it that I ended up taking over maintainership, which makes this a bit of a self-plug.
It also supports a full export of all stored metadata, so you have direct control over all of your valuable metadata.
It's not perfect, naturally, and its non-native nature means that fancy UIs just aren't possible, but it's designed to be an image repository, not an image editor...
I was doing this for a couple of years. Unfortunately the C/Dock II only supports PCI, which limits your graphics card choices considerably, but you can get modern low-end PCI cards still, and they're loads better than what my (reflashed) Inspiron 4100 came with (16Mb Radeon M6). Before I ended up replacing the machine altogether, I was using a Radeon 256MB 9250 card, which even gave me usable DX8-class grafix.
My current Acer laptop's eZDock is PCIe based (and even has an expresscard slot) so there's no inherent reason why they couldn't build a unit with a full PCIe slot for an external graphics card.
I wish I could find a link somewhere, but back in the Windows 3.x days, the days where serial mice were common, the days when _Mouse Systems_ actually meant something, the days when mice were ugly bricks, the days before the MS dove bar mouse, I remember seeing a mouse by Genius that had a front-center-mount scroll wheel.
The wheel wasn't clickable as a third button, but the spiel on the box was all about how it would make scrolling that much easier.
So Microsoft didn't invent the wheel mouse, but they did refine it considerably and make it universally usable, thanks to their ability to integrate tightly into the OS. It's so much easier to do that when you control the APIs.
Actually, their disk tests are fundamentally flawed. RAID0 is only good for boosting raw sustained throughput; it has pretty much no effect on access time. If you want a boost in access time, go for RAID1, as you can load-balance reads across two drives.
Furthermore, RAID0+1 is also not really worth it, as it still only gives you the ability to fail one drive, and instead of two logical spindle you only have one to do all of the work. But I suppose of your software is inflexible enough to only be able to operate on one partition, so be it.
I'd like to see some numbers for their boxes loaded up with RAM and high numbers of random I/O operations, which is where the high rotational speed of modern SCSI drives really shine. And this is the access pattern of a dynamic database-driven web site.
And as others have said, it's not the hardware that makes the most difference in these circumstances, it's how the software is set up, and how the site/database is coded.
Hell, I've completely saturated a 100mbps network serving dynamic content via pure Java Servlets, and this was only a dual P3-650. With a RAID5 array of 50G 7200RPM SCSI drives, hardly cutting edge even at the time. Dropping in a RAID1 array of WD120 IDE drives couldn't come anywhere close. But once the working set of data was loaded into RAM, they both performed about the same.
Their IDE raid setup is certianly considerably cheaper though, and that's a tradeoff that most people can easily make.
Bzzzzzt. Wrong.
Microsoft would be providing a common 802.11 MAC implementation. IEEE 802.11 is well-documented fully-open standard that ANYONE can download and implement
If MS made their implemtation with windows-only quirks, they wouldn't interoperate with every single card already out there.
And we're talking several million WiFi devices easily.
Manufacurers would be *more* likely to release specs, because the hardware and thus the programming interface would be much simpler.
- Pizza
Yes, you hit the nail on the head.
:)
These "Soft" WiFi cards still do full frame decoding, MAC matching and whatnot. They are roughly equal in intelligence to the average 10/100 ethernet card.
And in fact, most cards do WEP in the driver anyway.
As long as the hardware docs are published (register maps, DMA engine programming, etc) they'll work like a champ with Linux, that is once the host-based-mac stuff is further along.
(See one of my posts above for more details)
- Pizza [who does a lot of wireless driver hacking]
As someone who spends a considerable amount of time these days hacking on WiFi card drivers, Host-based MAC is actualla a VERY good thing.
A good analogy of this is PPP. The current situation is similar to a modem manufacturer embedding PPP in the hardware, which is horribly complex and expensive to implement. It is much simpler and cheaper to let the OS provide the PPP services.
WinModems come in two flavors; host-based controller and host-based signal processing. The latter is pure evil; the hardware is nothing more than a A/D/A converter, and the host CPU has to perform all DSP functions to make it into a modem. The host-based-controllers have real hardware DSPs and whatnot, but they just tell the DSP what to do, essentially replacing an on-board processor+firmware with the driver on the host machine.
WinWiFi (which is really host-based-MAC) is neither. The WinWiFi card would become about as smart as the average ethernet card; ie it would be able to transmit and receive raw 802.11 frames, and then pass them off to the driver which then figures out what to do with them.
A good portion of the wireless cards out there already do this, and nearly all of the new ones will do this. Why? complexity and cost.
802.11 is rather complicated. The MAC must handle a complex state machine; with all sorts of little nuances. Handling transmits/receives, and their acks, association, channel hopping, and then the real doozey: encryption.
WEP sucks. Not just because it's fundamentally broken, but because it takes a bit of oomph to work with, and it's a little complex. And if this is done in hardware, you can't update it to handle newer standards.
Every single one of the 802.11 extensions to replace/augment WEP will require considerably more computation power in hardware; but in fact, most 802.11 (windows) drivers now do WEP on the host, because it has far more computational power to spare with zero additional hardware cost.
This WinWiFi initiative is nothing more than "hey, all of you guys have already written this host-based-MAC stuff (or are going to have to write it anyway) so why not just use the stuff already part of the OS? It's already been extensively tested and that way, you don't need to reinvent the wheel."
It's called shared code, and makes a lot of sense.
I've been banging my head against the wall a lot lately because of buggy firmware in WiFi cards; If they let the host OS do the work instead, these bugs wouldn't exist, because the 802.11 spec is well-documented.
And again, it's not WinWiFi, it's Host-based-MAC. It's a work-in-progress for Linux too. And it is a GoodThing(tm).
- Pizza
Um, excuse-me?
1) Ever heard of the _Java Community Process_? nearly everything new to come into Java ThePlatform(tm) came through this. And anyone can participate in the JCP. Anyone.
2) I'll grant you that you need to get a license to implement the language.. but that's primarily there to ensure the quality of the implementations, which have to pass quite a validation process..
3) Microsoft didn't deviate from the spec *slightly*, they left gaping holes in their implementaion, and included all sorts of non-standard windows-specific stuff that negated the whole reason to use Java to begin with. People tried to use stuff coded to the java spec, and it broke on MS's VM. That's where the lawsuit came from.
If you make chances to the language, it is no longer Java, because the resulting language is different from what everyone else expects it to be.
Nobody can make changes to C, and still call it C and expect it to work anywhere. That's why there is ANSI C, to define what MUST be there for it to be called C. Have you ever tried to get code to compile under multiple compilers on the same platform? Java avoids these headaches because it is very rigidly specified.
And you're missing one very crucial point. C# is just another language, one of *thousands* of other languages. The language itself is remarkably unremarkable, much like Java, actually. There really isn't anything new from a language perspective.
The real power comes from the *platform* as a whole, including the class libraries one has access to. (After all, even C is pretty worthless without #include ) and I'll bet a nickel that 90% of the libs will remain windows-specific because they're being used via COM. Which is completely non-portable, and reduces you to once again doing Windows programming with yet another language. Big Whoop.
Whether the LANGUAGE is open or not is irrelevant. What matters is whether the rest of the system is open. (Aaside from the language and CLR spec, almost none of it is) And MS has an extremely poor track record in this regard with their propensity to embrace, extend, control , punish.
C# is a remarkable improvement to the way you develop Windows applications, but *everything* it does has already been done before; primarily by Java.
(...and freely implemented by anyone? Have you read the license for the CLR stuff? There's a reason that everyone involved in alternate implementations is deliberately avoinding being tainted by MS code)
- Pizza
You're wrong, actually. "Recording your favorite eposide while you're out for dinner" _is_ legal.
It doesn't matter what the studio says or not.
Wnder the DMCA, if the studio implemented some kind of technological access control (say, a flag that says "no timeshifting") then recording your favorite episode is still legal -- as long as you don't bypass the access control.
It's the act of bypassing the access control that's illegal under the DMCA, not the actual timeshifting itself. It's a crucial difference.
And that's why the general populace doesn't know.
Foolish Mortal.
I get 24fps rock-solid on my celeron 400, using XFree86 4.0.1 and a GeforceMX.
- Pizza
Perhaps I can be of assistence.
Got ~3.6G of disk space somewhere?
- Pizza
Sun DID develop a JDK for Linux.
JDK 1.3 SE has been out for at least a month now for Linux.
It completely whips the Blackdown 1.2.2 JDK in compilation and runtime speed.
Why is Java on the requirements of the job? Because perhaps it's java that generates the web pages. Perhaps it's java that the servers run on. Perhaps there are java components somewhere.
"Java makes it hard to do easy things and easy to do hard things."
probably about 50% of my development work is in Java, but you don't see any java applets or java code on our web pages.
Think before you speak.
If I'm going to spend $2000 on a recordable CD/DVD drive, I will want to be able to use it in high-end workstattions. Can you honestly tell me that people author movies and commercials on a PC?
If I'm going to have a couple hundred gigs of SCSI raid-5 storage for my video works in progress, I'm going to want to plug in a SCSI recorder as well. And there's no way I'm going to enable an IDE bus (or hell, install an IDE controller) in a system that has everything else already SCSI.
That said, I'll be very surprised if Pioneer doesn't release a SCSI version of this drive. Hell, they're one of the two companies that makes SCSI DVD-ROM drives. (the other being Toshiba).
Mass market acceptance means they'll have to do an IDE version. But at a $2000 price level, they're not looking for mass market acceptance.
Think about the GPL: People can resell it all they want for a modest duplication fee.
All the GPL guarantees is that if the University makes changes, they have to release the "new" thesis (ie the derived work) under the GPL.
I do DNS for microsoft-blo.ws and microsoftblo.ws
Guess I can expect to hear from Microsoft.