"ClearType" is a Microsoft branding term. The generalized term, subpixel rendering, is definitely supported under XFree86 and x.org. LCDs with multiple layout order of the RGB elements are even supported.
2.) automatic directX compatibility for games
WINE does this, but honestly, while there are a lot of game developers out there that know DirectX, there's nothing particularly magical about DirectX, and it'd be pretty hard to "just" do DirectX without supporting the other chunks of the Windows API (though I guess you could do a "DirectX-like" API). OpenGL is a truly open standard that's widely supported (and preferred by videocard developers), and SDL and its child libraries provide a more modular system than DirectX does.
one solid universal gui
I see why you want it, but it's not going to happen. Too many KDE people like KDE (which is, while not unbreakably, still strongly tied to Qt) and too many people have legal issues with Qt or prefer GNOME for technical reasons.
Honestly, I don't think it's all that necessary, either. Windows users have been using non-Windows widget sets for a long time in major apps -- Lotus Notes or Mozilla or any of the standard Win32 variants, which operate differently over the Win95-WinXP lifetime. People adapt pretty well. Both Qt and GTK are pretty snappy. Both interoperate pretty well today. Two widget sets is hardly a reason for a platform to fall apart.
Cygwin seems to run extremely fast and reliably already
Not that I'm saying that this is faster, but "fast and reliably"?
Perhaps I've been using a different Cygwin.
This isn't an attempt to bash the Cygwin developer team. It's an amazing work, and terribly useful. However, it simply is not as fast as running Linux on the same box -- the Windows VM and native filesystems don't do as well as the Linux VM and native filesystems, Cygwin needs a fair amount of overhead to translate some things, you have to deal with some oddball mappings and a sluggish terminal emulator. Some functionality that the Windows kernel doesn't really support (fork(), select()) has to be reimplemented at a higher, slower level. I'm still pretty sure that there's a bug in the select() implementation on a number of boxes that I've used Cygwin on -- occasionally, output of a couple of programs will hang until I tap a key, and then it'll start again.
Seriously, try building even a medium-sized *IX software package from source under Cygwin, and reconsider "reliable" -- there's going to be all kinds of interesting breakage.
(Note that I'm neutral toward your point that Cygwin fulfills many of the same goals as this does -- I just take issue with Cygwin being called particularly fast and reliable.)
Here is an argument for Linux-Windows compatibility.
Currently, a number of Linux-Windows compatibility projects catch a good deal of flak from Linux advocates. Cygwin seems to go mostly unscathed, but a lot of people bash WineX. Regular ol' wine catches some complaining, as does Crossover Office. Anything dealing with Microsoft servers (Exchange interoperability, for example) occasionally gets the same. Ports of Linux software to Windows sometimes catch flak.
A number of people seem to think that compatibility damages Linux. In the case of WineX ports, they worry that game companies may feel that advising users to use WineX is "good enough". In the case of ported Linux software to Windows, people feel that it decreases a Linux-only advantage, and brings Windows up to the level of Windows.
I think that these arguments generally fall flat.
Eric S. Raymond's fundamental thesis is that "Open Source works better than closed source." It isn't an ideological argument, a la Stallman's approach -- it's just that people are *better off* with Open Source. There is less duplication of labor, more value is promulgated to a greater number of people, bugs are more quickly fixed, etc.
Building on ESR's argument, I feel that it's reasonable to say that Linux is better than Windows in a number of ways -- furthermore, it improves more quickly. It is less expensive, provides a good amount of functionality, and has a good deal of focus on security. It is free.
Why, then, do people not use Linux instead of Windows? It's because of inertia -- it's difficult to have a Linux workstation interoperate nicely with a Windows one in a number of ways -- format and protocol compatibility are significant and operate strongly in Microsoft's favor. The leveraging of compatibility has served Microsoft well for years. They suck people into their camp, and then work hard to make it difficult to leave.
Projects that work to help Windows and Linux interoperate, I argue, assist Linux in the long run. In the short run, they may provide additional value to Windows users, or may allow someone to scrape along on Windows instead of moving to enjoy some crucial tool. However, they ultimately lower the compatibility barrier to switching, and some number of people will choose to switch. Those people make it more difficult for Microsoft to maintain compatibility barriers.
Ultimately, anyone that wants to see Linux become more popular knows that ultimately, those Windows users will have to manage to find their way across the divide. Making the path easier is a primary goal -- the strongest weapon Microsoft has of all is in keeping that gap wide. If there are lush meadows in the Linux world, but a vast canyon separating those meadows from the majority of the people, then those people will not move.
Let us say that GIMP is ported to Windows (it has been). Perhaps a number of people are able to use Windows to use the GIMP instead of having to install Linux. There are, however, few people that are likely to choose to switch to Linux just for the GIMP. However, now all those people are using a piece of software that exists, is open source, and works well on Linux -- in fact, if anything, it works better on Linux. They have been moved away from Photoshop or whatever else they'd be using that exists only on Windows. The next time they consider switching, instead of facing the loss of all their apps, they face the loss of only a few. And since Linux is ultimately better than Windows, they can begin to move across.
It is much easier to move to Linux today than it was a few years ago. There is usable (if not perfect) Office file format support, the ability to connect to Windows shares, and the ability to talk to many Microsoft servers. However, it is still not a trivial path. Most people are not willing to simply drop Windows and hope for the best, so it may involve repartitioning to allow dual-booting. There is a huge learning curve that must be overcome -- tech folks gene
It's not "fraught with complications" -- the repartitioning is the most technically involved step. It's just a pain in the butt to be rebooting your system and to have a set of apps that can't be running at the same time as another set of your apps.
You can't say that this won't take the world by storm. Just imagine -- a system with all the stability of Windows and the user-friendliness of Linux! What's not to like?
1: Users are forced to use antialiasing, or the fonts look like haywire.
I've no idea what "haywire" means. They will certainly look jaggy -- such is life without antialiasing. The same thing will happen with the Windows font renderer with aa text disabled.
2: If antialiased, they look fat and unreadable UNLESS you have a version of freetype and whatever fontserver you use, compiled *with the patentet hinting technology turned ON*.
(a) Most current apps use Xft and thus client-side font rendering, making poking at the fontserver unnecessary.
(b) Would you happen to provide the name of the font that looks "fat"? Does the following image (all lines generated using the autohinter) look "fat" to you? (note: image produced without using subpixel rendering, so if you're viewing this on an LCD, it won't look as nice as it could). This is a bit older (freetype 2.1.4 rather than current), but it shouldn't be too old to be roughly on top of things.
By "everything has to be rasterized" he is probably talking about the fact that you cannot draw antialiased anything on current X except by drawing the resulting composite into a local bitmap and sending it.
Ah, okay.
I agree with the original poster that this is a problem with the absurdly primitive X rendering model.
Mmm...I dunno. There *are* a few significant advantages to a client-side rendering system (though obviously a number of disadvantages).
The bad to the new Xft system:
* slower * more memory usage for the poor X server
The good:
* Applications are not constrained by the limitations of the X rendering architecture. This was a major holdup for AbiWord and other word processing/layout applications that require a lot of data about the font and potentially fancy kerning and other goodies.
* Applications are not constrained to using font types supported by the X server. I still remember using a special TrueType font server (xftt) just to be able to see TrueType fonts back in the days of server-side rendering, when XFree86 didn't know about TrueType. In the same way, new font formats can be easily added.
* Fonts don't have to be installed server-side to be used -- and (a biggie) fonts are easily *user installable*. You don't have to put in a request for your sysadmin to add a font any more.
* (really a side benefit of moving to Xft) font descriptors were user-intimidating -- Xft is much more friendly.
But an interface whereby which anything describable by even PostScript can be rendered by the server does not exist on any platform, except perhaps OS/X.
I don't really think PostScript is the greatest system in the world for handing rendering data around, honestly. It does have the nice benefit of allowing compatibility with PostScript devices, but it's really designed around a system that's easy to implement with simple hardware, not one that's efficient in a modern computer system.
A more accurate criticism of X is that they refused to add even the simplest "draw this image with alpha". This would get rid of about 90% of the reason GTK and other toolkits have to draw all their graphics in local memory and send it.
Huh? No, I believe that you're incorrect (unless you're talking about original, unextended X11). The Render extension, which most people are now using by virtue of XFree86/x.org, allows exactly this functionality -- sending pixmap data with alpha information and allowing the server to composite it. The difference from traditional X11 is that the client does the rendering from the vector data to the raster+alpha data, not that the client does the compositing itself. That would suck and require twice the latency and much more bandwidth. Keep in mind that the client can have the server cache pixmap data once it's been handed to the server.
Anti-aliased lines and shapes would be nice but Microsoft doesn't seem to be in any rush to do them either...
This is provided on both X11 (+ GLX extension, common and in x.org and XFree86 at least) and Windows via OpenGL. Not sure what the status of hardware acceleration on these is -- it used to be that only professional CAD cards had aa lines allowed in hardware. It was one of the few features allowing price discrimination. NVidia used to have a resistor or something removed in their consumer-class cards that disabled a couple of features, most notably aa lines. 3dfx's products supported only antialiasing on lines with a thickness of 1. This may have changed, and aa lines may be standard on current consumer hardware, for all I know.
Are the people who control Gnome even considering moving it to a new language?
No, but it makes good fodder around Slashdot, mostly among anti-MS advocates who want something to get riled up about and among a couple of vocal KDE trolls, so several rather misleading stories have slipped their way in. Miguel has been saying for something like two years now that GNOME is not going to be moved to.NET, and that the people claiming it are full of it. Naturally, once a story gets rolling, people happily continue to propagate horseshit.
Here are a few choice quotes from Miguel, the guy doing Mono who also happens to work on GNOME:
The short story is: rewriting code does not pay off, and I agree with the thesis of the article. Rewriting GNOME in C# with the CLR would be a very bad idea, if not the worst possible idea ever.
GNOME is not adopting Mono or.NET as an implementation technology. The headline from the Register is misleading, for a number of reasons:
* The headline does not reflect any statements I made on the interview (if you read the interview you will notice this).
* The only future plans that have been approved by the GNOME team (which has 11 voting members on its board) are found here:
http://developer.gnome.org/dotplan/
* I am not the GNOME foundation or control GNOME like Linus controls his kernel, I am just its founder and a contributor.
* GNOME is not built by an individual, its built by a team of roughly 500 contributors in many areas.
* Decisions in the GNOME world are done by active contributors and module maintainers. I have given
my maintainership status on every module I maintained to other members of the GNOME team as I got more involved with Ximian and later on with Mono.
So effectively I have no "maintainer" control.
and
GNOME had always tried to have a good support for multiple programming languages, because we realize that no matter how much we loved C as a programming language, there was a large crowd of people out there that would like to use the GNOME libraries from their favorite programming language, which might not necessarily be C.
This strategy has paid off very well. There are healthy and striving Python, Perl, Guile and Ada communities out there that use the Gtk+ and Gnome bindings to build applications. From rapid prototyping to robust applications: we wanted to empower developers.
The actual scope of.NET interest:
After much researching and debating, we decided that a couple of developers at Ximian will join me in working on a free implementation of these specifications. [.NET/Mono]
This means that there are a few developers who *also* happen to work on GNOME that work on Mono. Guess what? There are people that work on KDE that work on Java -- that certainly does not mean that "KDE is moving to Java". A couple of Ximian developers working on.NET and GNOME support for.NET is akin to a random KDE-related company (like The Kompany) working on a particular application. Miguel's *only goal* is to have an environment for Ximian to develop future applications for. That means that Ximian may produce an application or two written in C#. It is even possible that such an application could become a core GNOME application.
Miguel has stated in the past that he is dubious about doing rewriting even GNOME-based applications maintained by Ximian -- primarily Evolution. I just can't understand why people have so much problem getting this into their skulls.
I am not sure what people told Richard Stallman about my plans. Given the confusion surrounding.NET, it is very possible that people were asking `Miguel wants to depend on Passport' or something just as bad as that.
It is always compiled with AA in any distribution I've seen.
It is sometimes not compiled with support for kerning using a particular system that Apple has patented. It has an autokerning system that can also be used. In general, I've found that autokerning looks slightly worse on the few fonts out there that are extremely polished (like Verdana, say), but significantly better on anything else.
KDE uses FreeType as well (if indirectly), as does any TrueType rendering system I know of under *IX.
"Windows is better than linux because you can get all of the functionality of linux (by installing linux), but you can only get Windows by installing Windows"
You can install cygwin under Windows, or WINE under Linux. It all depends what your primary operating environment is.
Its like a MS interface except not any better. Really it's almost identical in terms of layout and usibility.
Well, for 31337 users like you, there are DEs like GNUStep, ROX, and many more open source alternatives. Or, if you find the entire concept of a premade DE to be objectionable, there are vanilla WMs like sawfish, E, fvwm, blackbox, and many more alternative window managers -- combine one with gkrellm or xload/xclock or an alternative system monitor and maybe something like xbindkeys, and you've whipped yourself up an X11 environment.
I find it somewhat difficult to believe that you've tried the dozens or more choices in each category and simply found that there is *no* combination that suits your fancy.
Besides, as far as KDE has come, it isn't even close. You can't copy and paste between EVERY application.
Care to give an example? Qt's old days of broken clipboards are a long time in the past.
Fonts look like CRAP.
You've got to be kidding. Fonts look at least as nice under a modern system as they do on a Windows box -- good fonts (like Vera) are finally included, and the rendering and antialiasing is certainly on par with any other rendering system I've seen.
Everything has to be rasterized to be displayed (including eps files).
What are you talking about? I doubt there is a single system in existence on Earth that can display EPS without rasterizing it. Maybe an analog pen-based plotter. I've yet to see *anything* like this.
Uh...okay, if this thing is smacking into the moon at 4000mph, it's a pretty good bet that they aren't using braking thrusters (or else they'd increase the amount of the braking fuel and be selling people *non*-disintegrated stuff landed on the Moon). The Moon has a negligable atmosphere. That means that the ball will be hitting the surface in excess of negative escape velocity.
So if you have a perfectly elastic collision, as you assumed, your ball will escape the gravitational pull of the Moon, and rebound out into space.
Is flag burning immoral? It doesn't create much pollution, either.
I certainly wouldn't have any problem with burning a flag -- it would be on the same level as calling Rev. Jesse Jackson a stupid cotton-picker. It really doesn't *do* anything aside from piss a number of people off that feel strongly about the issue.
Spyware is a big problem which isn't Window's fault.
Not actually true.
Windows could provide a capability-limiting system that would make it extremely difficult for spyware to be installed (no network access to this utility, etc).
OTOH, no existing desktop operating system that I know of does provide such a system.
There are three bits in the *IX permission system relating to setting id.
The first is the suid bit, and states that a file shall be executed euid the owner of that file. This is often used for making small programs run with root privileges (like passwd).
The second is the sgid bit. It does the same thing the suid bit does, but for the owning group of the file.
The third is the sticky bit. It once hinted to VMs to cache the file in memory for future executions on an executable file. It is now ignored in this role, but when set on a directory, it changes the way the permission system works for files in that directory. Normally, if a user has write access to a directory, they may remove or rename files/empty directories in that directory. The sticky bit means that the kernel also checks to see whether the user owns either the sticky directory or the file/directory in that directory being named or removed before allowing a remove/rename. The only directory that I know of that this is normally set on in a *IX system is/tmp.
I can't wait until this country turns into nothing but a bunch of Amazon.com warehouses with residential apartments in between, with little to no retail. THEN consumers will finally understand what they got themselves into
Um...more efficient, centralized production and distribution with a very low cost to entry and easy scalability?
I fail to see how that's a bad thing.
For many types of stores, brick and mortar is phenomenally wasteful. Some guy is paid to stand around in a store all day, and occasionally talk to people, and do the mechanical acts of taking money and putting it into a register. That's a *waste*.
Not such a bad system, honestly, but I don't think your assessment is fair since New Hampshire has no real urban areas or blight to deal with and just doesn't need a lot of the infrastructure that a "real" state (one with a more substantive population) requires.
You know...one really has to wonder.
The idea of urban areas is that they're more efficient. You can centralize and reduce transportation costs. New Hampshire lacks those, so presumably is under even tougher constraints.
Yet New Hampshire manages to do just fine with*out* urban areas, without a sales tax, and without an income tax.
Ads replicated from the real world and simple insertion of ads or more product placement are two very different things.
If you are reproducing a real-world environment that contains ads, yes, most people are not going to have a problem with you replicating the ads. It adds to the realism.
On the other hand, if you are simply dumping product labels into a game, frequently flashing them, and your main dedication during the game production is simply to ensure that gamers are exposed to a product in conjunction with something "cool" as much as possible, then you are not improving the game -- you are subtlely degrading the reality of the game throughout. I could see this turning into Tomorrow Never Dies or some similar piece of marketing garbage. I like being able to sit back and simply enjoy something without keeping a weather eye on how people are trying to influence me.
The problem is that the people here (marketers) arguing in *favor* of ads in games are trying to leverage the few special cases where ads improve the game.
Furthermore, product placement limits creativity. Sure, you *could* do a game set 1000 years in the future or the past, but it's really hard to do product placement. Much easier with an FPS taking place in modern day times.
I hope everybody knows that the creator of nmap is a criminal, and used his port scanner tool for illegal purposes.
Uh, huh.
When Phil Zimmerman released PGP, he underwent a three-year investigation by the FBI.
I not care in the least what either Phil or Fyodor did (especially when Fyodor was tracking down a harasser). They produce excellent software, which is their only interaction with me.
There is a lot of content on Slashdot that could be considered libel. If every person guilty of libel on Slashdot was ignored, we'd have an awfully quiet forum.
Slashdot Mirror
cleartype fonts
"ClearType" is a Microsoft branding term. The generalized term, subpixel rendering, is definitely supported under XFree86 and x.org. LCDs with multiple layout order of the RGB elements are even supported.
2.) automatic directX compatibility for games
WINE does this, but honestly, while there are a lot of game developers out there that know DirectX, there's nothing particularly magical about DirectX, and it'd be pretty hard to "just" do DirectX without supporting the other chunks of the Windows API (though I guess you could do a "DirectX-like" API). OpenGL is a truly open standard that's widely supported (and preferred by videocard developers), and SDL and its child libraries provide a more modular system than DirectX does.
one solid universal gui
I see why you want it, but it's not going to happen. Too many KDE people like KDE (which is, while not unbreakably, still strongly tied to Qt) and too many people have legal issues with Qt or prefer GNOME for technical reasons.
Honestly, I don't think it's all that necessary, either. Windows users have been using non-Windows widget sets for a long time in major apps -- Lotus Notes or Mozilla or any of the standard Win32 variants, which operate differently over the Win95-WinXP lifetime. People adapt pretty well. Both Qt and GTK are pretty snappy. Both interoperate pretty well today. Two widget sets is hardly a reason for a platform to fall apart.
Cygwin seems to run extremely fast and reliably already
Not that I'm saying that this is faster, but "fast and reliably"?
Perhaps I've been using a different Cygwin.
This isn't an attempt to bash the Cygwin developer team. It's an amazing work, and terribly useful. However, it simply is not as fast as running Linux on the same box -- the Windows VM and native filesystems don't do as well as the Linux VM and native filesystems, Cygwin needs a fair amount of overhead to translate some things, you have to deal with some oddball mappings and a sluggish terminal emulator. Some functionality that the Windows kernel doesn't really support (fork(), select()) has to be reimplemented at a higher, slower level. I'm still pretty sure that there's a bug in the select() implementation on a number of boxes that I've used Cygwin on -- occasionally, output of a couple of programs will hang until I tap a key, and then it'll start again.
Seriously, try building even a medium-sized *IX software package from source under Cygwin, and reconsider "reliable" -- there's going to be all kinds of interesting breakage.
(Note that I'm neutral toward your point that Cygwin fulfills many of the same goals as this does -- I just take issue with Cygwin being called particularly fast and reliable.)
Here is an argument for Linux-Windows compatibility.
Currently, a number of Linux-Windows compatibility projects catch a good deal of flak from Linux advocates. Cygwin seems to go mostly unscathed, but a lot of people bash WineX. Regular ol' wine catches some complaining, as does Crossover Office. Anything dealing with Microsoft servers (Exchange interoperability, for example) occasionally gets the same. Ports of Linux software to Windows sometimes catch flak.
A number of people seem to think that compatibility damages Linux. In the case of WineX ports, they worry that game companies may feel that advising users to use WineX is "good enough". In the case of ported Linux software to Windows, people feel that it decreases a Linux-only advantage, and brings Windows up to the level of Windows.
I think that these arguments generally fall flat.
Eric S. Raymond's fundamental thesis is that "Open Source works better than closed source." It isn't an ideological argument, a la Stallman's approach -- it's just that people are *better off* with Open Source. There is less duplication of labor, more value is promulgated to a greater number of people, bugs are more quickly fixed, etc.
Building on ESR's argument, I feel that it's reasonable to say that Linux is better than Windows in a number of ways -- furthermore, it improves more quickly. It is less expensive, provides a good amount of functionality, and has a good deal of focus on security. It is free.
Why, then, do people not use Linux instead of Windows? It's because of inertia -- it's difficult to have a Linux workstation interoperate nicely with a Windows one in a number of ways -- format and protocol compatibility are significant and operate strongly in Microsoft's favor. The leveraging of compatibility has served Microsoft well for years. They suck people into their camp, and then work hard to make it difficult to leave.
Projects that work to help Windows and Linux interoperate, I argue, assist Linux in the long run. In the short run, they may provide additional value to Windows users, or may allow someone to scrape along on Windows instead of moving to enjoy some crucial tool. However, they ultimately lower the compatibility barrier to switching, and some number of people will choose to switch. Those people make it more difficult for Microsoft to maintain compatibility barriers.
Ultimately, anyone that wants to see Linux become more popular knows that ultimately, those Windows users will have to manage to find their way across the divide. Making the path easier is a primary goal -- the strongest weapon Microsoft has of all is in keeping that gap wide. If there are lush meadows in the Linux world, but a vast canyon separating those meadows from the majority of the people, then those people will not move.
Let us say that GIMP is ported to Windows (it has been). Perhaps a number of people are able to use Windows to use the GIMP instead of having to install Linux. There are, however, few people that are likely to choose to switch to Linux just for the GIMP. However, now all those people are using a piece of software that exists, is open source, and works well on Linux -- in fact, if anything, it works better on Linux. They have been moved away from Photoshop or whatever else they'd be using that exists only on Windows. The next time they consider switching, instead of facing the loss of all their apps, they face the loss of only a few. And since Linux is ultimately better than Windows, they can begin to move across.
It is much easier to move to Linux today than it was a few years ago. There is usable (if not perfect) Office file format support, the ability to connect to Windows shares, and the ability to talk to many Microsoft servers. However, it is still not a trivial path. Most people are not willing to simply drop Windows and hope for the best, so it may involve repartitioning to allow dual-booting. There is a huge learning curve that must be overcome -- tech folks gene
It's not "fraught with complications" -- the repartitioning is the most technically involved step. It's just a pain in the butt to be rebooting your system and to have a set of apps that can't be running at the same time as another set of your apps.
You can't say that this won't take the world by storm. Just imagine -- a system with all the stability of Windows and the user-friendliness of Linux! What's not to like?
1: Users are forced to use antialiasing, or the fonts look like haywire.
I've no idea what "haywire" means. They will certainly look jaggy -- such is life without antialiasing. The same thing will happen with the Windows font renderer with aa text disabled.
2: If antialiased, they look fat and unreadable UNLESS you have a version of freetype and whatever fontserver you use, compiled *with the patentet hinting technology turned ON*.
(a) Most current apps use Xft and thus client-side font rendering, making poking at the fontserver unnecessary.
(b) Would you happen to provide the name of the font that looks "fat"? Does the following image (all lines generated using the autohinter) look "fat" to you? (note: image produced without using subpixel rendering, so if you're viewing this on an LCD, it won't look as nice as it could). This is a bit older (freetype 2.1.4 rather than current), but it shouldn't be too old to be roughly on top of things.
By "everything has to be rasterized" he is probably talking about the fact that you cannot draw antialiased anything on current X except by drawing the resulting composite into a local bitmap and sending it.
Ah, okay.
I agree with the original poster that this is a problem with the absurdly primitive X rendering model.
Mmm...I dunno. There *are* a few significant advantages to a client-side rendering system (though obviously a number of disadvantages).
The bad to the new Xft system:
* slower
* more memory usage for the poor X server
The good:
* Applications are not constrained by the limitations of the X rendering architecture. This was a major holdup for AbiWord and other word processing/layout applications that require a lot of data about the font and potentially fancy kerning and other goodies.
* Applications are not constrained to using font types supported by the X server. I still remember using a special TrueType font server (xftt) just to be able to see TrueType fonts back in the days of server-side rendering, when XFree86 didn't know about TrueType. In the same way, new font formats can be easily added.
* Fonts don't have to be installed server-side to be used -- and (a biggie) fonts are easily *user installable*. You don't have to put in a request for your sysadmin to add a font any more.
* (really a side benefit of moving to Xft) font descriptors were user-intimidating -- Xft is much more friendly.
But an interface whereby which anything describable by even PostScript can be rendered by the server does not exist on any platform, except perhaps OS/X.
I don't really think PostScript is the greatest system in the world for handing rendering data around, honestly. It does have the nice benefit of allowing compatibility with PostScript devices, but it's really designed around a system that's easy to implement with simple hardware, not one that's efficient in a modern computer system.
A more accurate criticism of X is that they refused to add even the simplest "draw this image with alpha". This would get rid of about 90% of the reason GTK and other toolkits have to draw all their graphics in local memory and send it.
Huh? No, I believe that you're incorrect (unless you're talking about original, unextended X11). The Render extension, which most people are now using by virtue of XFree86/x.org, allows exactly this functionality -- sending pixmap data with alpha information and allowing the server to composite it. The difference from traditional X11 is that the client does the rendering from the vector data to the raster+alpha data, not that the client does the compositing itself. That would suck and require twice the latency and much more bandwidth. Keep in mind that the client can have the server cache pixmap data once it's been handed to the server.
Anti-aliased lines and shapes would be nice but Microsoft doesn't seem to be in any rush to do them either...
This is provided on both X11 (+ GLX extension, common and in x.org and XFree86 at least) and Windows via OpenGL. Not sure what the status of hardware acceleration on these is -- it used to be that only professional CAD cards had aa lines allowed in hardware. It was one of the few features allowing price discrimination. NVidia used to have a resistor or something removed in their consumer-class cards that disabled a couple of features, most notably aa lines. 3dfx's products supported only antialiasing on lines with a thickness of 1. This may have changed, and aa lines may be standard on current consumer hardware, for all I know.
Are the people who control Gnome even considering moving it to a new language?
.NET, and that the people claiming it are full of it. Naturally, once a story gets rolling, people happily continue to propagate horseshit.
.NET as an implementation technology. The headline from the Register is misleading, for a number of reasons:
.NET interest:
.NET and GNOME support for .NET is akin to a random KDE-related company (like The Kompany) working on a particular application. Miguel's *only goal* is to have an environment for Ximian to develop future applications for. That means that Ximian may produce an application or two written in C#. It is even possible that such an application could become a core GNOME application.
.NET, it is very possible that people were asking `Miguel wants to depend on Passport' or something just as bad as that.
No, but it makes good fodder around Slashdot, mostly among anti-MS advocates who want something to get riled up about and among a couple of vocal KDE trolls, so several rather misleading stories have slipped their way in. Miguel has been saying for something like two years now that GNOME is not going to be moved to
Here are a few choice quotes from Miguel, the guy doing Mono who also happens to work on GNOME:
The short story is: rewriting code does not pay off, and I agree with the thesis of the article. Rewriting GNOME in C# with the CLR would be a very bad idea, if not the worst possible idea ever.
GNOME is not adopting Mono or
* The headline does not reflect any statements I made on the interview (if you read the interview you will notice this).
* The only future plans that have been approved by the GNOME team (which has 11 voting members on its board) are found here:
http://developer.gnome.org/dotplan/
* I am not the GNOME foundation or control GNOME like Linus controls his kernel, I am just its founder and a contributor.
* GNOME is not built by an individual, its built by a team of roughly 500 contributors in many areas.
* Decisions in the GNOME world are done by active contributors and module maintainers. I have given
my maintainership status on every module I maintained to other members of the GNOME team as I got more involved with Ximian and later on with Mono.
So effectively I have no "maintainer" control.
and
GNOME had always tried to have a good support for multiple programming languages, because we realize that no matter how much we loved C as a programming language, there was a large crowd of people out there that would like to use the GNOME libraries from their favorite programming language, which might not necessarily be C.
This strategy has paid off very well. There are healthy and striving Python, Perl, Guile and Ada communities out there that use the Gtk+ and Gnome bindings to build applications. From rapid prototyping to robust applications: we wanted to empower developers.
The actual scope of
After much researching and debating, we decided that a couple of developers at Ximian will join me in working on a free implementation of these specifications. [.NET/Mono]
This means that there are a few developers who *also* happen to work on GNOME that work on Mono. Guess what? There are people that work on KDE that work on Java -- that certainly does not mean that "KDE is moving to Java". A couple of Ximian developers working on
Miguel has stated in the past that he is dubious about doing rewriting even GNOME-based applications maintained by Ximian -- primarily Evolution. I just can't understand why people have so much problem getting this into their skulls.
I am not sure what people told Richard Stallman about my plans. Given the confusion surrounding
My only i
Linux has been desktop-ready since 1991, it's just that the majority of users haven't been ready for it.
Uh...I'm pretty sure that Linux couldn't run any X11 system in '91. It *definitely* was not exactly trivial to install Linux in '91.
If you said "since 2002", I might buy into that.
Not exactly true.
It is always compiled with AA in any distribution I've seen.
It is sometimes not compiled with support for kerning using a particular system that Apple has patented. It has an autokerning system that can also be used. In general, I've found that autokerning looks slightly worse on the few fonts out there that are extremely polished (like Verdana, say), but significantly better on anything else.
KDE uses FreeType as well (if indirectly), as does any TrueType rendering system I know of under *IX.
"Windows is better than linux because you can get all of the functionality of linux (by installing linux), but you can only get Windows by installing Windows"
You can install cygwin under Windows, or WINE under Linux. It all depends what your primary operating environment is.
Its like a MS interface except not any better. Really it's almost identical in terms of layout and usibility.
Well, for 31337 users like you, there are DEs like GNUStep, ROX, and many more open source alternatives. Or, if you find the entire concept of a premade DE to be objectionable, there are vanilla WMs like sawfish, E, fvwm, blackbox, and many more alternative window managers -- combine one with gkrellm or xload/xclock or an alternative system monitor and maybe something like xbindkeys, and you've whipped yourself up an X11 environment.
I find it somewhat difficult to believe that you've tried the dozens or more choices in each category and simply found that there is *no* combination that suits your fancy.
Besides, as far as KDE has come, it isn't even close. You can't copy and paste between EVERY application.
Care to give an example? Qt's old days of broken clipboards are a long time in the past.
Fonts look like CRAP.
You've got to be kidding. Fonts look at least as nice under a modern system as they do on a Windows box -- good fonts (like Vera) are finally included, and the rendering and antialiasing is certainly on par with any other rendering system I've seen.
Everything has to be rasterized to be displayed (including eps files).
What are you talking about? I doubt there is a single system in existence on Earth that can display EPS without rasterizing it. Maybe an analog pen-based plotter. I've yet to see *anything* like this.
Uh...okay, if this thing is smacking into the moon at 4000mph, it's a pretty good bet that they aren't using braking thrusters (or else they'd increase the amount of the braking fuel and be selling people *non*-disintegrated stuff landed on the Moon). The Moon has a negligable atmosphere. That means that the ball will be hitting the surface in excess of negative escape velocity.
So if you have a perfectly elastic collision, as you assumed, your ball will escape the gravitational pull of the Moon, and rebound out into space.
You two nitwits put peanut butter and H2CO3 in my nice clean glass!
Is flag burning immoral? It doesn't create much pollution, either.
I certainly wouldn't have any problem with burning a flag -- it would be on the same level as calling Rev. Jesse Jackson a stupid cotton-picker. It really doesn't *do* anything aside from piss a number of people off that feel strongly about the issue.
As an American, I would like to second that opinion.
Spyware is a big problem which isn't Window's fault.
Not actually true.
Windows could provide a capability-limiting system that would make it extremely difficult for spyware to be installed (no network access to this utility, etc).
OTOH, no existing desktop operating system that I know of does provide such a system.
There are three bits in the *IX permission system relating to setting id.
/tmp.
The first is the suid bit, and states that a file shall be executed euid the owner of that file. This is often used for making small programs run with root privileges (like passwd).
The second is the sgid bit. It does the same thing the suid bit does, but for the owning group of the file.
The third is the sticky bit. It once hinted to VMs to cache the file in memory for future executions on an executable file. It is now ignored in this role, but when set on a directory, it changes the way the permission system works for files in that directory. Normally, if a user has write access to a directory, they may remove or rename files/empty directories in that directory. The sticky bit means that the kernel also checks to see whether the user owns either the sticky directory or the file/directory in that directory being named or removed before allowing a remove/rename. The only directory that I know of that this is normally set on in a *IX system is
He might be "mooching", but he's also injecting Canadian money into the US economy.
I can't wait until this country turns into nothing but a bunch of Amazon.com warehouses with residential apartments in between, with little to no retail. THEN consumers will finally understand what they got themselves into
Um...more efficient, centralized production and distribution with a very low cost to entry and easy scalability?
I fail to see how that's a bad thing.
For many types of stores, brick and mortar is phenomenally wasteful. Some guy is paid to stand around in a store all day, and occasionally talk to people, and do the mechanical acts of taking money and putting it into a register. That's a *waste*.
Not such a bad system, honestly, but I don't think your assessment is fair since New Hampshire has no real urban areas or blight to deal with and just doesn't need a lot of the infrastructure that a "real" state (one with a more substantive population) requires.
You know...one really has to wonder.
The idea of urban areas is that they're more efficient. You can centralize and reduce transportation costs. New Hampshire lacks those, so presumably is under even tougher constraints.
Yet New Hampshire manages to do just fine with*out* urban areas, without a sales tax, and without an income tax.
What are they doing right?
The federal government has no right to levy an income tax.
It has no right to establish and enforce almost all of the federal laws in existence.
That doesn't really seem to have stopped it, though.
Ads replicated from the real world and simple insertion of ads or more product placement are two very different things.
If you are reproducing a real-world environment that contains ads, yes, most people are not going to have a problem with you replicating the ads. It adds to the realism.
On the other hand, if you are simply dumping product labels into a game, frequently flashing them, and your main dedication during the game production is simply to ensure that gamers are exposed to a product in conjunction with something "cool" as much as possible, then you are not improving the game -- you are subtlely degrading the reality of the game throughout. I could see this turning into Tomorrow Never Dies or some similar piece of marketing garbage. I like being able to sit back and simply enjoy something without keeping a weather eye on how people are trying to influence me.
The problem is that the people here (marketers) arguing in *favor* of ads in games are trying to leverage the few special cases where ads improve the game.
Furthermore, product placement limits creativity. Sure, you *could* do a game set 1000 years in the future or the past, but it's really hard to do product placement. Much easier with an FPS taking place in modern day times.
I hope everybody knows that the creator of nmap is a criminal, and used his port scanner tool for illegal purposes.
Uh, huh.
When Phil Zimmerman released PGP, he underwent a three-year investigation by the FBI.
I not care in the least what either Phil or Fyodor did (especially when Fyodor was tracking down a harasser). They produce excellent software, which is their only interaction with me.
There is a lot of content on Slashdot that could be considered libel. If every person guilty of libel on Slashdot was ignored, we'd have an awfully quiet forum.