Really? Wow, I didn't know that. And only 5 years late, too!
GNOME's been using it for ages. I suspect KDE has as well.
*way* better? Really? Wow! Better than ClearType? WOW!!!
ClearType, aside from having a name that some marketroid thought up, is hardly mind-boggling. "ClearType" is a trademarked name, but the technique used in it -- taking advantage of sub-pixel LCD layout -- is definitely supported by freetype. GNOME even ships with a control panel to let you set one of four different slight variations on the antialiasing method, so you can pick the algorithm that you like best.
That being said, last time I looked with the intent to compare (which was years ago), Microsoft's antialiased fonts didn't *look* quite as nice as what freetype produced but tended to be slightly more readable -- Microsoft's renderer seems to go to a good deal of effort to avoid AAing vertical and horizontal pipes, which tends to improve contrast a bit.
"Real" means real, nothing more and nothing less. As in Windows 2000/XP and OS X. You'd think that for KDE to claim this "feature" (whatever that means) maybe they could have "really" implemented it, eh? I mean, instead of drawing whatever's behind the top-level window? Much hilarity ensues when you move them around!!
You are correct that this is a source of unending XFree86 embarassment. XFree86 had pseudotransparency for *ages* before Windows or Mac OS, and has now fallen behind the times. This is, I believe, scheduled for XFree86 5.x. There are patches out to let you do this today (and have been for quite some time), if you want the functionality, but you'll be looking at some compilation.
It also hit me that KDE seems to have more K-programs than GNOME has G-programs now, which is just ugly.
Two reasons.
The first is that there are a lot more pieces of GNOME software out there than KDE-using software. The degree of awfulness of the naming scheme is to some degree a function of the number of pieces of software using it. People got *really* fed up of "g-this" and "g-that" all day.
Second of all, the KDE project is a bit more tightly knit, the GNOME project a bit more distributed. You have a bunch of people building a piece of software for the KDE suite, and a lot of people just using GNOME because it's there, not interested in promoting their software as part of the GNOME Project.
Re:I still cant help but be a little disappointed.
on
Review: KDE 3.2
·
· Score: 2, Insightful
Well, there are a couple of good reasons (and I *do* wish that KDE followed Windows a wee bit less closely, a la GNOME).
* First, Windows has become ubiquitous in the past ten years. Everyone knows Windows. That's how they expect computers to operate. This has produced a barrier to entry for anyone that chooses a different method.
* Second, the approach is pretty good. Remember that Microsoft themselves chose to use Apple's design. It isn't perfect, but there *have* been significant improvements made in the KDE projects (some degree of accelerator rebinding functionality provided to users, though less than GNOME provides, tearable panes, support for multiple viewports...)
* Third, if nothing else, this can be treated as a transitional system to get people onto a platform where new ideas *can* be implemented.
What would happen, if a small portion of the code got used in another game under a license for example the GPL. Microsoft would come down on them like a ton of bricks.
I'm sure that Microsoft would be more than enthusiastic about turnabout. This is *precisely* what they've been complaining about with the GPL -- that it's risky that an engineer with a tight timeline might simply grab all that tanalizing open source sitting out in the open to solve a problem, then claim that the software was written by him. We have to play by the same rules that Microsoft does -- following rules on each side is only fair.
And if Microsoft incorporated, say, chunks of glibc into Windows's closed-source C runtime, I think it's a fair bet to say that the FSF would drag them through the coals both legally and from a PR standpoint.
No, this license is decidedly unlike the GPL. This license is somewhat akin to the Mozilla Public License (which was dropped due to people complaining). Basically, Microsoft and Microsoft alone gets rights roughly equivalent (though slightly more in their favor) than the BSD license. They get royalty-free rights to do anything they want to with your code.
On the other hand, the rights granted to *non*-Microsoft entities are much more restrictive -- non-commercial only.
Effectively, this makes you a free coder for Microsoft -- the only company that can ever financially benefit from the code you produce is Microsoft.
This is *not* a turnaround for Microsoft (other than the fact that they are opening some of their own code, which is a change). From a commercial standpoint, they are giving up zero IP (they do not allow you to use copyrighted or patented information, which may be present in their release. This is very different from the GPL, where copyrighted data must be available for commercial use, and you *cannot* have patents on methods used in the software. Microsoft has previously promoted BSD-like licenses that would allow them profit. This license is notable in that it is GPL-incompatible.
From a strategic point of view, there is little Microsoft stands to risk here. The program is, as others have pointed out, written in DirectX, and would be difficult to port to anything other than Windows (well, perhaps other than the X-Box). It might assist a small amount in improving WINE, but that's about it.
I'm not sure whether this includes a data file release -- this is the only thing that weirds me out, as doing so would be extremely unusual. I would expect not, but ~600 MB seems excessive for source code alone. Perhaps if someone could check this out?
That being said, I'm certainly not going to complain -- I see very few ways in which we are worse off after this release. This is a clear win for former fans and players of the game. Microsoft *has* done a few notable things that I would not have expected of them. They have not placed legal restrictions on porting, though there may be a practical limitation. I suppose one could argue that Microsoft is hoping to start a trend of companies doing open-source releases chosing not to use the GPL, but that seems a bit conspiracy theory-oriented even for Slashdot.
The only concern I can think of is Microsoft's worries about PR with this move. It may not be much of an issue -- recently, there has been a good amount of business hyping of "open source". Microsoft hasn't been bashing "open source" much in the past year or so -- just the GPL. It's a reasonable supposition that this has been intentional from a strategic standpoint.
Another weird thing is that Microsoft Research is the organization doing the release. That's very, very odd. I strongly suspect that Microsoft Research is *not* where the entertainment division is located (Bungie isn't a subdivision of Microsoft Reesearch), so unless they are responsible for old software, I can't see why they're involved. Could be that they're a bit more academia-oriented, and that there's some scientist pushing for open-sourcing something that doesn't have significant IP value to Microsoft any more.
If Microsoft wants to test the waters for non-GPL open source possibilities, this is a very good, safe way for them to do so. This game still has active users. Game technology moves so quickly that a four-year-old-game has little that folks might steal from them -- and in any case, Microsoft is not releasing any of their previous IP.
I *really* wish Microsoft would open-source the Close Combat series (they probably don't own copyright on it, but it's a nice thought). Microsoft or no, I'd be willing to buy copies of all of the series if I could get an open source Linux-compatible copy -- that series is phenomenal.
The whole concept of an "auto-renewing" system even being considered acceptable just really burns me up. There's no good reason for companies not being forced to re-request a payment once a year. Let the burden be on the company to ensure that the consumer still wants the product, rather than on the consumer to ensure that he doesn't get shafted.
This is why I wish everyone would use smartcards. While theoretically you could build an auto-payment authorization system with one, it isn't just a matter of "company A has your CC# and can charge you whatever they want to charge."
Given our current technology, the Earth will definitely recover (biologically, and may take a long time) from anything we do. I suppose that it might be possible to wipe out all humans, though it would be awfully difficult.
Freenet's problem is not bandwidth. Freenet clients are capable of getting fairly good bandwidth.
Freenet's problems center more around:
* The choice of default interface. Normally, the way you work with Freenet is through a web browser. I'm sure this seemed like a good idea at the time (cross platform, eliminates some code), but it actually brings out a huge number of flaws. It is extremely latency-sensitive, it requires browser reconfiguration for any kind of sane use (with 200 or so simultaneous connections), it is still very easy to eat up all available connections when visiting a page that has, say, a number of thumbnails on it.
* Latency sucks. Latency really sucks. This would not be a problem if Freenet worked mostly through background batch processes, but Freenet was chosen to be used through a web browser, which means interactive latency is required. It can take ten minutes (admittedly, this is on the high side) for a Freenet request to wend its way through the queue and finally let the next page load). This makes Freenet web interface extremely unpleasant to use.
* Resource usage. I had a machine that ran *all* my servers before. It was a PII/266 with half a gig of RAM. Freenet killed it, eating memory like a big and maxing out the CPU frequently -- while supporting a single user. The reference (and I believe, only current) implementation is in Java. A stronger argument against Java's resource usage could not be produced.
* Poor data persistence. The Freenet authors have made some improvements in the past year or so, but, frankly, if I publish a page, some of the images may be missing soon.
Freenet is an (extremely) neat research project, but despite constant claims from Freenet fans ("Oh, *this* time we have lots of improvements") that Freenet is really "ready for use" this time, it has consistently shown itself not to be generally usable.
Correct me if I'm mistaken, but wasn't the Kazaa network designed so that it doesn't rely on a central server? In that case, even if the company disappears, the network should still be around as long as people are wanting to use it to trade music.
You are correct, but your conclusion is not (and it's not your fault, either -- it's good ol' politics and business obscuring good clean engineering).
Kazaa operates in a fairly decentralized manner. At one point, the FastTrack network (what Kazaa uses internally) was open. However, the protocol was reverse engineered (by the GiFT project members and others), and third party clients started popping up. The FastTrack folks sold licenses to use their network -- plus, the use of an open protocol was detrimental to the client vendors, like Kazaa, as it meant that users could choose a (nicer) spyware-free client. The protocol was modified to contain an authentication system that *is* centralized. If Kazaa (the company) won't authorize you, you can't use the network.
The addition of the authentication system was a huge step back from an engineering standpoint, but a huge jump forward from a business one -- it make Kazaa very lucrative.
CNN also likes "media". Criticizing "the media" seems to be hip these days, so CNN goes right ahead and does it. It really doesn't get much more ironic...
Actually, it does. I remember at one point CNN running a tidbit on whether excessive media coverage of some political event was having negative impact...this was followed immediately by a teaser for more CNN ocverage of said event.
It consistently amazes me how far Australia is behind the rest of the world in both a legal and political sense.
What possible justification is there for having a legal structure for allowing non-law-enforcement people seize data?
I'm reminded of the project run by a journalist once. The local police chief had been gathering the garbage of a suspected criminal, and going through it without a warrant. The journalist wrote a critical article, and the police chief and local mayor responded, saying that they were entirely in the right (as this was garbage, unwanted material), and that they had no ethical problems with the use of garbage for examination. The journalist responded by going through the trash of the mayor and police chief for a week and writing an article containing all the dirt this allowed them to dig up on the two.
* 3.5" floppies have locking tabs. This is a pretty simple, physical way to ensure that you don't accidently erase something important. It would be easy to put this on USB drives (a switch might cost 5 cents more), but it isn't done. For CDs, this is already in place.
* Floppies are rewriteable. CDRs are not, and -RWs are still not in a particularly nice way. It's easy to just dump a file on a floppy. For USB drives, this is already in place.
* Floppies are truly universal. Unless you're dealing with a Mac, a machine *will* have a floppy drive. Network connectivity could be down, the thing might not have USB support (getting quite rare), but machines dating back *ages* have floppies.
* Floppies don't push media constraints much. If machine A can read a floppy, machine B probably can as well. I find that a CD burned by one drive may well not be readable by another.
* Floppies are cheap. CDs are cheap, but USB drives are not. I can just give someone a floppy with a document on it and not worry about it. The same is not true of USB drives.
* For troubleshooting, I may want to boot into some kind of emergency environment (say, Knoppix or Superrescue) on a CD. Many machines have only one CD drive, and using the emergency CD ties this drive up. If I also want somewhere to write data (IP address/network information etc), I need another device. Floppies work well, CDs don't (unless you have multiple CD drives). USB drives probably work.
* There are some devices with floppy output still in use -- older digital cameras being the biggie.
So, I guess what I want to say is that most things the floppy can do can be replicated by *either* the CD or the USB drive, but not by a single one. It has a pretty unique role.
That being said, I *very* rarely use my floppy drive. Next time I put together a computer, I could save $5 by leaving it out -- but the benefit of having it it, the knowledge that there's a pretty solid universal interchange device in there is just worth the $5 to me.
Why should it be built to last a lifetime? I mean, you *can* build all sorts of things to last a lifetime, but it's not particularly economically sensible or desireable. Much like the grandparent poster, I have never replaced the battery in a digital watch, as I have never managed to avoid losing a watch long enough for the battery to run out. I admit that most of the features above basic time-telling are probably extraneous, but I do occasionally use a stopwatch, and day of week/month are useful.
I do vaguely like the look of some analog watches, but it's to the same extent that I vaguely like the look of a trackball or a hammer or a fan -- I just don't really care much about how the thing looks -- just how it works. I don't exactly spend time admiring my watch -- I just want the time from it.
I tend to mar faceplates. I don't care how ruggedly built they are, they *will* get scratched. If the watch is a $30 digital watch, it's no big deal. If it's a $200 analog watch, I do care.
I could never figure out people that say that they can "see the time more quickly on an analog watch". It's just nonsensical -- you see it, you know. Perhaps if someone is extremely familiar with their analog watch and doesn't use any devices with LCD digits, they might take a moment to pick up on the thing, but when I look at my watch, it's just like reading a word in your post -- it's there, in my head. A digital watch has the benefit of giving an accurate time reading immediately.
This isn't to bash people with analog watches. There are good reasons for them. They're a status symbol -- it lets someone clearly say that they can blow a lot of money on an expensive watch, or let the NASA folks say "I worked on the Mars lander project". There's a good deal of tradition associated with them, and tradition is fun. It's fun to put up a Christmas tree each year, and it's fun to get an heirloom watch.
However, there just aren't any significant criticisms of digital watches that really hold true any more. I tend to think that unless people prefer analog watches for a particular reason, they're better off with a digital, but neither mechanism is badly flawed for people who just want the time.
That's what I was just posting about. I admit that the ratio is a bit cuff-of-sleeve -- but if we use the average case of 3 PowerPC cycles per 1 x86 cycles, we get a requirement of 733 * 3 = ~2200 million PPC cycles per second, where we only have ~2000 million PPC cycles per second to work with. Plus those numbers are decidedly conservative in Microsoft's favor. MS has to work with the worst-case situation, not average-case, since games need to be real-time (unless you want your old games to be jerky or drop sound on particular games or at particular points -- or, actually, simply fail to work).
Except most of the cycles on the 733MHz (not Ghz!) x86 CPU are spent inside DirectX. The emu layer wouldn't bother emulating DirectX/x86; it would use a native PPC version. The emulation's only going to be necessary for game logic. That probably accounts for only a tiny fraction of a CPU, for most games.
On a personal computer platform, you would probably be correct. However, the X-Box is a console, and differs in a number of important ways. One is that the "OS" and "libraries" are not separate from the application -- they are shipped with the application. In the case of the X-Box, they are statically linked to DirectX. (There's also other ugliness involved in the build process that I'm not all that familiar with.) Anyway, the point is that the DirectX code that is run would be part of the shipped game. The only way to pull off what you're advocating would be to try to infer, as the game is launched on a PPC XB2, what chunks of the game are DirectX and modify code that points to that code to point to PowerPC native versions. This is not particularly trivial or reliable -- it's the approach that cxbx, the only remotely usable X-Box emulator that I know of, uses, and it is still effectively unusable after many, many hours of work.
Because there's a really easy call in the Win32 API that "opens" a file, or does whatever Explorer defines as opening that file. Mail programs are encouraged to piggyback off this Explorer functionality. Said call was not developed when network security was an issue, and "integrating" office suites and the OS was a primary goal of MS. Apple was doing the same thing with OpenDoc.
A) no one needs a "feature" like this. Save to Disk and then run if neccesary.
This is not a fix. The same "open this with whatever program you're using" call takes place when the user double-clicks the icon. This just adds another step. I doubt users are inadvertently clicking on "open". They simply don't realize the consequences of opening the file.
C) a warning dialog after the double-click is useless. The person has already decided to run the program, to them it just seems like annoying interference from their stupid computer.
Agreed.
The UNIX CLI takes a different approach. The Mac OS/Windows/GNOME/KDE DEs take the approach of having a "default action" for a filetype. This means that if a user does not know what a file is, they can inadvertently perform an unknown action on that fiel by double-clicking it. The UNIX CLI dictates that a user must know what program uses the file and choose to execute that program on the file before the program is executed. This provides somewhat better security -- the user is *forced* to understand what he is doing before he is allowed to perform the action -- at the cost of a much steeper learning curve.
Even this is somewhat vulnerable. Unfortunately, there are many ways to embed active content in seemingly harmless files..doc files simply allow one to include active content in the form of macros, but there are plenty of other approaches. Think of the number of servers that have had remote buffer overflows over the years. Now consider whether software authors generally apply the same level of dilligence in robustly handling garbage data files as they do incoming remote network connections. If WinAMP's MP3 handler has a buffer overflow on, say, overlength ID3 tags (note that roughly this *has* happened in WinAMP before), then worms can spread simply by users opening even known, trusted content in apparently understood files. ("Well, Bob sent me this new MP3 of Britney Spears orgasming, and I just wanted to hear it...")
The main currently available solutions are:
* Don't use C/C++ in favor of something with bounds checking. Unfortunately, most current alternatives suck. If there was something with the good design of ocaml but was an imperative language, we might be going somewhere.
* *Robustly* check everything coming into and out of a program, and verify any assumptions before trusting data. We've been trying to do this for years, and authors still fail to do this properly. Unlikely that this will work as a final solution.
* Sandbox all programs at the OS level. This requires significant effort on the part of application and OS vendors, and while it makes screwups harder to do accidentally, there's always a temptation to bypass security features to make a coding job easier.
* Sandbox untrusted data, similar to what some trusted operating systems do -- enforce data flow, but across multiple systems. This would require Internet-wide infrastructure changes and PKI to be put in place -- something that has a huge number of its own difficulties.
* Limit forms of data interchange. This has been tried and hasn't worked too well -- people want functionality. Firewalls and HTTP proxies were put up to keep people from running applications over the network -- and today, we just use SOAP. Making people only able to send text email attachments is just too limiting.
* Push blame onto end users or IT. This is not a solution, but it's what's mostly happened -- Microsoft and other vendors have consistently blamed
Why anyone uses anything besides LaTeX to prepare documents is beyond me.
Perhaps because it's a lot easier to train someone to use the tools capable of outputting.doc files (especially since that frequently means zero training today) than it is to train them to use the tools capable of outputting LaTeX files?
I dunno. There are criticisms that you could make in favor of Bush's administration, but "trustworthy" just isn't one.
Clinton was untrustworthy about what he did with his penis -- an, in my opinion, thoroughly more acceptable issue than Bush, who has been untrustworthy about reasons for sending a country to war.
As far as I can tell, this is because PHB's can't understand many, many technical issues. However, minor formatting issues provide an almost unlimited source for work that an almost completely unskilled person can criticize and understand -- i.e. them. Hence, massive amount of effort is blown on formatting efforts.
I believe the font problem is actually Apple's fault.
WYSIWYG was a big selling point of the Mac (remember, this was the era of DOS WordPerfect). The standard Mac screen resolution (though not, to the best of my knowledge, ever guaranteed by Apple) was 72 DPI. TextSize() was specified as taking the font size in number of *points*, not pixels.
When Microsoft ripped off a good deal of Apple work, they happened to use a similar API (using points at *all* for onscreen work). However, *unlike* Apple, they did not have control over the hardware in the wild.
The rest is just sordid history. Apple spent an absolutely stupid amount of time trying to hack around differences in onscreen/printed format with Display Postscript and a complicated imaging model as Classic Mac OS started to get old.
The point-based font rendering worked roughly on the Mac because, even though the entire non-font onscreen rendering scheme was pixel based, there was (at least originally) a 1:1 correspondence. On Windows, the API *also* used pixel-based positioning (*except* for a few random things like dialogs), but didn't have the corespondence.
To be honest, GTK+ is the first sane widget set I'd used. Instead of specifying pixels positions (which, unfortunately, can still be done), the widget library handles positioning most things -- you just pack widgets in where you'd like them, something like HTML. It's the first vaguely sane step to allow different screen resolutions.
You're thinking of onscreen use, where you are absolutely right, due to poor screen resolution. I still cannot figure out why web browsers *still* ship by default displaying many fonts as serif by default. It's simply stupid in terms ofusability.
From what I can tell from other analysis here, the new rule applies to printed documents, where serif fonts really are easier to read for large chunks of text.
Slashdot Mirror
Really? Wow, I didn't know that. And only 5 years late, too!
GNOME's been using it for ages. I suspect KDE has as well.
*way* better? Really? Wow! Better than ClearType? WOW!!!
ClearType, aside from having a name that some marketroid thought up, is hardly mind-boggling. "ClearType" is a trademarked name, but the technique used in it -- taking advantage of sub-pixel LCD layout -- is definitely supported by freetype. GNOME even ships with a control panel to let you set one of four different slight variations on the antialiasing method, so you can pick the algorithm that you like best.
That being said, last time I looked with the intent to compare (which was years ago), Microsoft's antialiased fonts didn't *look* quite as nice as what freetype produced but tended to be slightly more readable -- Microsoft's renderer seems to go to a good deal of effort to avoid AAing vertical and horizontal pipes, which tends to improve contrast a bit.
"Real" means real, nothing more and nothing less. As in Windows 2000/XP and OS X. You'd think that for KDE to claim this "feature" (whatever that means) maybe they could have "really" implemented it, eh? I mean, instead of drawing whatever's behind the top-level window? Much hilarity ensues when you move them around!!
You are correct that this is a source of unending XFree86 embarassment. XFree86 had pseudotransparency for *ages* before Windows or Mac OS, and has now fallen behind the times. This is, I believe, scheduled for XFree86 5.x. There are patches out to let you do this today (and have been for quite some time), if you want the functionality, but you'll be looking at some compilation.
It also hit me that KDE seems to have more K-programs than GNOME has G-programs now, which is just ugly.
Two reasons.
The first is that there are a lot more pieces of GNOME software out there than KDE-using software. The degree of awfulness of the naming scheme is to some degree a function of the number of pieces of software using it. People got *really* fed up of "g-this" and "g-that" all day.
Second of all, the KDE project is a bit more tightly knit, the GNOME project a bit more distributed. You have a bunch of people building a piece of software for the KDE suite, and a lot of people just using GNOME because it's there, not interested in promoting their software as part of the GNOME Project.
Well, there are a couple of good reasons (and I *do* wish that KDE followed Windows a wee bit less closely, a la GNOME).
* First, Windows has become ubiquitous in the past ten years. Everyone knows Windows. That's how they expect computers to operate. This has produced a barrier to entry for anyone that chooses a different method.
* Second, the approach is pretty good. Remember that Microsoft themselves chose to use Apple's design. It isn't perfect, but there *have* been significant improvements made in the KDE projects (some degree of accelerator rebinding functionality provided to users, though less than GNOME provides, tearable panes, support for multiple viewports...)
* Third, if nothing else, this can be treated as a transitional system to get people onto a platform where new ideas *can* be implemented.
Ooops -- I meant the Netscape Public License, not the Mozilla Public License. Heh.
What would happen, if a small portion of the code got used in another game under a license for example the GPL. Microsoft would come down on them like a ton of bricks.
I'm sure that Microsoft would be more than enthusiastic about turnabout. This is *precisely* what they've been complaining about with the GPL -- that it's risky that an engineer with a tight timeline might simply grab all that tanalizing open source sitting out in the open to solve a problem, then claim that the software was written by him. We have to play by the same rules that Microsoft does -- following rules on each side is only fair.
And if Microsoft incorporated, say, chunks of glibc into Windows's closed-source C runtime, I think it's a fair bet to say that the FSF would drag them through the coals both legally and from a PR standpoint.
FreeBSD solved such simple issues very cleanly nearly a decade ago now with the ports system, why can't Linux?
What on earth are you talking about?
Ports provides zero legal benefits over any of the Linux network software distribution methods (apt, yum, etc).
No, this license is decidedly unlike the GPL. This license is somewhat akin to the Mozilla Public License (which was dropped due to people complaining). Basically, Microsoft and Microsoft alone gets rights roughly equivalent (though slightly more in their favor) than the BSD license. They get royalty-free rights to do anything they want to with your code.
On the other hand, the rights granted to *non*-Microsoft entities are much more restrictive -- non-commercial only.
Effectively, this makes you a free coder for Microsoft -- the only company that can ever financially benefit from the code you produce is Microsoft.
This is *not* a turnaround for Microsoft (other than the fact that they are opening some of their own code, which is a change). From a commercial standpoint, they are giving up zero IP (they do not allow you to use copyrighted or patented information, which may be present in their release. This is very different from the GPL, where copyrighted data must be available for commercial use, and you *cannot* have patents on methods used in the software. Microsoft has previously promoted BSD-like licenses that would allow them profit. This license is notable in that it is GPL-incompatible.
From a strategic point of view, there is little Microsoft stands to risk here. The program is, as others have pointed out, written in DirectX, and would be difficult to port to anything other than Windows (well, perhaps other than the X-Box). It might assist a small amount in improving WINE, but that's about it.
I'm not sure whether this includes a data file release -- this is the only thing that weirds me out, as doing so would be extremely unusual. I would expect not, but ~600 MB seems excessive for source code alone. Perhaps if someone could check this out?
That being said, I'm certainly not going to complain -- I see very few ways in which we are worse off after this release. This is a clear win for former fans and players of the game. Microsoft *has* done a few notable things that I would not have expected of them. They have not placed legal restrictions on porting, though there may be a practical limitation. I suppose one could argue that Microsoft is hoping to start a trend of companies doing open-source releases chosing not to use the GPL, but that seems a bit conspiracy theory-oriented even for Slashdot.
The only concern I can think of is Microsoft's worries about PR with this move. It may not be much of an issue -- recently, there has been a good amount of business hyping of "open source". Microsoft hasn't been bashing "open source" much in the past year or so -- just the GPL. It's a reasonable supposition that this has been intentional from a strategic standpoint.
Another weird thing is that Microsoft Research is the organization doing the release. That's very, very odd. I strongly suspect that Microsoft Research is *not* where the entertainment division is located (Bungie isn't a subdivision of Microsoft Reesearch), so unless they are responsible for old software, I can't see why they're involved. Could be that they're a bit more academia-oriented, and that there's some scientist pushing for open-sourcing something that doesn't have significant IP value to Microsoft any more.
If Microsoft wants to test the waters for non-GPL open source possibilities, this is a very good, safe way for them to do so. This game still has active users. Game technology moves so quickly that a four-year-old-game has little that folks might steal from them -- and in any case, Microsoft is not releasing any of their previous IP.
I *really* wish Microsoft would open-source the Close Combat series (they probably don't own copyright on it, but it's a nice thought). Microsoft or no, I'd be willing to buy copies of all of the series if I could get an open source Linux-compatible copy -- that series is phenomenal.
The whole concept of an "auto-renewing" system even being considered acceptable just really burns me up. There's no good reason for companies not being forced to re-request a payment once a year. Let the burden be on the company to ensure that the consumer still wants the product, rather than on the consumer to ensure that he doesn't get shafted.
This is why I wish everyone would use smartcards. While theoretically you could build an auto-payment authorization system with one, it isn't just a matter of "company A has your CC# and can charge you whatever they want to charge."
Given our current technology, the Earth will definitely recover (biologically, and may take a long time) from anything we do. I suppose that it might be possible to wipe out all humans, though it would be awfully difficult.
Freenet's problem is not bandwidth. Freenet clients are capable of getting fairly good bandwidth.
Freenet's problems center more around:
* The choice of default interface. Normally, the way you work with Freenet is through a web browser. I'm sure this seemed like a good idea at the time (cross platform, eliminates some code), but it actually brings out a huge number of flaws. It is extremely latency-sensitive, it requires browser reconfiguration for any kind of sane use (with 200 or so simultaneous connections), it is still very easy to eat up all available connections when visiting a page that has, say, a number of thumbnails on it.
* Latency sucks. Latency really sucks. This would not be a problem if Freenet worked mostly through background batch processes, but Freenet was chosen to be used through a web browser, which means interactive latency is required. It can take ten minutes (admittedly, this is on the high side) for a Freenet request to wend its way through the queue and finally let the next page load). This makes Freenet web interface extremely unpleasant to use.
* Resource usage. I had a machine that ran *all* my servers before. It was a PII/266 with half a gig of RAM. Freenet killed it, eating memory like a big and maxing out the CPU frequently -- while supporting a single user. The reference (and I believe, only current) implementation is in Java. A stronger argument against Java's resource usage could not be produced.
* Poor data persistence. The Freenet authors have made some improvements in the past year or so, but, frankly, if I publish a page, some of the images may be missing soon.
Freenet is an (extremely) neat research project, but despite constant claims from Freenet fans ("Oh, *this* time we have lots of improvements") that Freenet is really "ready for use" this time, it has consistently shown itself not to be generally usable.
Correct me if I'm mistaken, but wasn't the Kazaa network designed so that it doesn't rely on a central server? In that case, even if the company disappears, the network should still be around as long as people are wanting to use it to trade music.
You are correct, but your conclusion is not (and it's not your fault, either -- it's good ol' politics and business obscuring good clean engineering).
Kazaa operates in a fairly decentralized manner. At one point, the FastTrack network (what Kazaa uses internally) was open. However, the protocol was reverse engineered (by the GiFT project members and others), and third party clients started popping up. The FastTrack folks sold licenses to use their network -- plus, the use of an open protocol was detrimental to the client vendors, like Kazaa, as it meant that users could choose a (nicer) spyware-free client. The protocol was modified to contain an authentication system that *is* centralized. If Kazaa (the company) won't authorize you, you can't use the network.
The addition of the authentication system was a huge step back from an engineering standpoint, but a huge jump forward from a business one -- it make Kazaa very lucrative.
CNN also likes "media". Criticizing "the media" seems to be hip these days, so CNN goes right ahead and does it. It really doesn't get much more ironic...
Actually, it does. I remember at one point CNN running a tidbit on whether excessive media coverage of some political event was having negative impact...this was followed immediately by a teaser for more CNN ocverage of said event.
It consistently amazes me how far Australia is behind the rest of the world in both a legal and political sense.
What possible justification is there for having a legal structure for allowing non-law-enforcement people seize data?
I'm reminded of the project run by a journalist once. The local police chief had been gathering the garbage of a suspected criminal, and going through it without a warrant. The journalist wrote a critical article, and the police chief and local mayor responded, saying that they were entirely in the right (as this was garbage, unwanted material), and that they had no ethical problems with the use of garbage for examination. The journalist responded by going through the trash of the mayor and police chief for a week and writing an article containing all the dirt this allowed them to dig up on the two.
Ah, floppy benefits. Okay:
* 3.5" floppies have locking tabs. This is a pretty simple, physical way to ensure that you don't accidently erase something important. It would be easy to put this on USB drives (a switch might cost 5 cents more), but it isn't done. For CDs, this is already in place.
* Floppies are rewriteable. CDRs are not, and -RWs are still not in a particularly nice way. It's easy to just dump a file on a floppy. For USB drives, this is already in place.
* Floppies are truly universal. Unless you're dealing with a Mac, a machine *will* have a floppy drive. Network connectivity could be down, the thing might not have USB support (getting quite rare), but machines dating back *ages* have floppies.
* Floppies don't push media constraints much. If machine A can read a floppy, machine B probably can as well. I find that a CD burned by one drive may well not be readable by another.
* Floppies are cheap. CDs are cheap, but USB drives are not. I can just give someone a floppy with a document on it and not worry about it. The same is not true of USB drives.
* For troubleshooting, I may want to boot into some kind of emergency environment (say, Knoppix or Superrescue) on a CD. Many machines have only one CD drive, and using the emergency CD ties this drive up. If I also want somewhere to write data (IP address/network information etc), I need another device. Floppies work well, CDs don't (unless you have multiple CD drives). USB drives probably work.
* There are some devices with floppy output still in use -- older digital cameras being the biggie.
So, I guess what I want to say is that most things the floppy can do can be replicated by *either* the CD or the USB drive, but not by a single one. It has a pretty unique role.
That being said, I *very* rarely use my floppy drive. Next time I put together a computer, I could save $5 by leaving it out -- but the benefit of having it it, the knowledge that there's a pretty solid universal interchange device in there is just worth the $5 to me.
Why should it be built to last a lifetime? I mean, you *can* build all sorts of things to last a lifetime, but it's not particularly economically sensible or desireable. Much like the grandparent poster, I have never replaced the battery in a digital watch, as I have never managed to avoid losing a watch long enough for the battery to run out. I admit that most of the features above basic time-telling are probably extraneous, but I do occasionally use a stopwatch, and day of week/month are useful.
I do vaguely like the look of some analog watches, but it's to the same extent that I vaguely like the look of a trackball or a hammer or a fan -- I just don't really care much about how the thing looks -- just how it works. I don't exactly spend time admiring my watch -- I just want the time from it.
I tend to mar faceplates. I don't care how ruggedly built they are, they *will* get scratched. If the watch is a $30 digital watch, it's no big deal. If it's a $200 analog watch, I do care.
I could never figure out people that say that they can "see the time more quickly on an analog watch". It's just nonsensical -- you see it, you know. Perhaps if someone is extremely familiar with their analog watch and doesn't use any devices with LCD digits, they might take a moment to pick up on the thing, but when I look at my watch, it's just like reading a word in your post -- it's there, in my head. A digital watch has the benefit of giving an accurate time reading immediately.
This isn't to bash people with analog watches. There are good reasons for them. They're a status symbol -- it lets someone clearly say that they can blow a lot of money on an expensive watch, or let the NASA folks say "I worked on the Mars lander project". There's a good deal of tradition associated with them, and tradition is fun. It's fun to put up a Christmas tree each year, and it's fun to get an heirloom watch.
However, there just aren't any significant criticisms of digital watches that really hold true any more. I tend to think that unless people prefer analog watches for a particular reason, they're better off with a digital, but neither mechanism is badly flawed for people who just want the time.
That's what I was just posting about. I admit that the ratio is a bit cuff-of-sleeve -- but if we use the average case of 3 PowerPC cycles per 1 x86 cycles, we get a requirement of 733 * 3 = ~2200 million PPC cycles per second, where we only have ~2000 million PPC cycles per second to work with. Plus those numbers are decidedly conservative in Microsoft's favor. MS has to work with the worst-case situation, not average-case, since games need to be real-time (unless you want your old games to be jerky or drop sound on particular games or at particular points -- or, actually, simply fail to work).
Except most of the cycles on the 733MHz (not Ghz!) x86 CPU are spent inside DirectX. The emu layer wouldn't bother emulating DirectX/x86; it would use a native PPC version. The emulation's only going to be necessary for game logic. That probably accounts for only a tiny fraction of a CPU, for most games.
On a personal computer platform, you would probably be correct. However, the X-Box is a console, and differs in a number of important ways. One is that the "OS" and "libraries" are not separate from the application -- they are shipped with the application. In the case of the X-Box, they are statically linked to DirectX. (There's also other ugliness involved in the build process that I'm not all that familiar with.) Anyway, the point is that the DirectX code that is run would be part of the shipped game. The only way to pull off what you're advocating would be to try to infer, as the game is launched on a PPC XB2, what chunks of the game are DirectX and modify code that points to that code to point to PowerPC native versions. This is not particularly trivial or reliable -- it's the approach that cxbx, the only remotely usable X-Box emulator that I know of, uses, and it is still effectively unusable after many, many hours of work.
Why would you ever want to do this?
.doc files simply allow one to include active content in the form of macros, but there are plenty of other approaches. Think of the number of servers that have had remote buffer overflows over the years. Now consider whether software authors generally apply the same level of dilligence in robustly handling garbage data files as they do incoming remote network connections. If WinAMP's MP3 handler has a buffer overflow on, say, overlength ID3 tags (note that roughly this *has* happened in WinAMP before), then worms can spread simply by users opening even known, trusted content in apparently understood files. ("Well, Bob sent me this new MP3 of Britney Spears orgasming, and I just wanted to hear it...")
Because there's a really easy call in the Win32 API that "opens" a file, or does whatever Explorer defines as opening that file. Mail programs are encouraged to piggyback off this Explorer functionality. Said call was not developed when network security was an issue, and "integrating" office suites and the OS was a primary goal of MS. Apple was doing the same thing with OpenDoc.
A) no one needs a "feature" like this. Save to Disk and then run if neccesary.
This is not a fix. The same "open this with whatever program you're using" call takes place when the user double-clicks the icon. This just adds another step. I doubt users are inadvertently clicking on "open". They simply don't realize the consequences of opening the file.
C) a warning dialog after the double-click is useless. The person has already decided to run the program, to them it just seems like annoying interference from their stupid computer.
Agreed.
The UNIX CLI takes a different approach. The Mac OS/Windows/GNOME/KDE DEs take the approach of having a "default action" for a filetype. This means that if a user does not know what a file is, they can inadvertently perform an unknown action on that fiel by double-clicking it. The UNIX CLI dictates that a user must know what program uses the file and choose to execute that program on the file before the program is executed. This provides somewhat better security -- the user is *forced* to understand what he is doing before he is allowed to perform the action -- at the cost of a much steeper learning curve.
Even this is somewhat vulnerable. Unfortunately, there are many ways to embed active content in seemingly harmless files.
The main currently available solutions are:
* Don't use C/C++ in favor of something with bounds checking. Unfortunately, most current alternatives suck. If there was something with the good design of ocaml but was an imperative language, we might be going somewhere.
* *Robustly* check everything coming into and out of a program, and verify any assumptions before trusting data. We've been trying to do this for years, and authors still fail to do this properly. Unlikely that this will work as a final solution.
* Sandbox all programs at the OS level. This requires significant effort on the part of application and OS vendors, and while it makes screwups harder to do accidentally, there's always a temptation to bypass security features to make a coding job easier.
* Sandbox untrusted data, similar to what some trusted operating systems do -- enforce data flow, but across multiple systems. This would require Internet-wide infrastructure changes and PKI to be put in place -- something that has a huge number of its own difficulties.
* Limit forms of data interchange. This has been tried and hasn't worked too well -- people want functionality. Firewalls and HTTP proxies were put up to keep people from running applications over the network -- and today, we just use SOAP. Making people only able to send text email attachments is just too limiting.
* Push blame onto end users or IT. This is not a solution, but it's what's mostly happened -- Microsoft and other vendors have consistently blamed
I'm pretty sure he was being sarcastic and driving home your point.
"Freedom Font"
Why anyone uses anything besides LaTeX to prepare documents is beyond me.
.doc files (especially since that frequently means zero training today) than it is to train them to use the tools capable of outputting LaTeX files?
Perhaps because it's a lot easier to train someone to use the tools capable of outputting
I dunno. There are criticisms that you could make in favor of Bush's administration, but "trustworthy" just isn't one.
Clinton was untrustworthy about what he did with his penis -- an, in my opinion, thoroughly more acceptable issue than Bush, who has been untrustworthy about reasons for sending a country to war.
As far as I can tell, this is because PHB's can't understand many, many technical issues. However, minor formatting issues provide an almost unlimited source for work that an almost completely unskilled person can criticize and understand -- i.e. them. Hence, massive amount of effort is blown on formatting efforts.
I believe the font problem is actually Apple's fault.
WYSIWYG was a big selling point of the Mac (remember, this was the era of DOS WordPerfect). The standard Mac screen resolution (though not, to the best of my knowledge, ever guaranteed by Apple) was 72 DPI. TextSize() was specified as taking the font size in number of *points*, not pixels.
When Microsoft ripped off a good deal of Apple work, they happened to use a similar API (using points at *all* for onscreen work). However, *unlike* Apple, they did not have control over the hardware in the wild.
The rest is just sordid history. Apple spent an absolutely stupid amount of time trying to hack around differences in onscreen/printed format with Display Postscript and a complicated imaging model as Classic Mac OS started to get old.
The point-based font rendering worked roughly on the Mac because, even though the entire non-font onscreen rendering scheme was pixel based, there was (at least originally) a 1:1 correspondence. On Windows, the API *also* used pixel-based positioning (*except* for a few random things like dialogs), but didn't have the corespondence.
To be honest, GTK+ is the first sane widget set I'd used. Instead of specifying pixels positions (which, unfortunately, can still be done), the widget library handles positioning most things -- you just pack widgets in where you'd like them, something like HTML. It's the first vaguely sane step to allow different screen resolutions.
You're thinking of onscreen use, where you are absolutely right, due to poor screen resolution. I still cannot figure out why web browsers *still* ship by default displaying many fonts as serif by default. It's simply stupid in terms ofusability.
From what I can tell from other analysis here, the new rule applies to printed documents, where serif fonts really are easier to read for large chunks of text.