I agree to some extent. However, I would imagine that most people's views on Israel are less informed than you think -- I'd wager that the average American doesn't know what country Israel is in conflict with.
Americans don't seem to know or care much about Israel at all. "America" reportedly has an opinion on the matter, but that's the government, not the population.
On one hand, many people do not seek outside news sources. On the other hand, they are not nearly as widely available as localized news sources in America. Other countries' media outlets are more well-connected. I would doubt that this fact is a result of specific action by the populations of other countries, but more a result of geographic factors.
I often wonder whether policy makers have even heard of a systems approach to security.
In the media, infrequently asked questions include:
What action is this intended to prevent? Hopefully, it is obvious that security measures should prevent serious threats to security.
Will the proposed measure prevent this action? There's no point in building a security fence which doesn't completely encircle the object which it's intended to protect. If alternate routes are readily available, a security measure gives a false sense of security, while doing little to prevent actual abuse.
What sort of audit system is in place to ensure that the proposed methods will stand up against abuse? Systems which can be abused will be abused, given enough time. If systems are not available for independent review they should not be trusted.
There is no ego trip among many of the citizens. There is massive ignorance of real international affairs by the media, but we American citizens don't control American media.
I'll tell you what. Since you're an expert on all things wrong with America, why don't you provide examples of us Americans following our government's every whim?
Try to back it up with actual facts where possible.
I'm sorry but I had no trouble understanding all the parts you say have no explaination:
Okie, let's examine these, since you seem to be claiming that these parts are explained. I'm interested in seeing the third movie if they do explain these things, but if they just present them as "Neo can do whatever he wants in the real world too. Just believe it, please!" then I'd rather not waste my time and money.
*Neo stopped the sentinels because, apparently, his powers are not limited to just the matrix, but are actually in the real world too.
Okay, but how do his "powers" carry over into the "real world"?
It was my impression from having seen the first two episodes that Neo was able to step outside of the rules of the Matrix because the system was designed to be believable by its occupants. As a result, it would allow Neo to do what he believed he could do. Since he knew that the system's rules didn't apply to him, the Matrix did his bidding.
When you say, "his powers are not limited to just the matrix", to which powers are you referring? His powers within the Matrix are limited to presenting his set of beliefs to the system (that he could fly, etc.) and allowing the system to present a reality to him which matched those beliefs.
Your claim that Neo's power to know that the Matrix is fake extends to the real world. That I can believe.
However, how does his knowing-that-the-Matrix-is-fake allow him to manipulate robots in the real world?
Smith entered Bane by somehow hijacking the hardline or something I guess, I just kind of look at it as he found a way to the subway station (what the hell was with making the portal between worlds a subway station anyway?) and then entered the real world.
The parent poster basically said that he wasn't sure how Smith entered a real person. You say, "I just kind of look at it as he found a way to the subway station... and then entered the real world."
In short:
Parent> I don't see how he entered the real world. You> He found a subway station, then entered the real world.
The parent wasn't questioning Smith's ability to locate a subway station (in fact, he was in a subway station in the original movie), but wondered how Smith (a piece of software) could control a human.
I'll agree that these two points are rather hard to accept, but it is a movie.
That's what the parent was complaining about! Playing the "it's just a movie" card when somebody complains about plot holes doesn't excuse the fact that there are holes in the plot.
Again, in dialogue form: Person> That road is full of potholes, and my car's suspension is bad from driving on it! What crappy roads Pennsylvania has! Other person> I'll agree that having your car suffer damage is disappointing, but it is just a road. Person> Whatever. It's still a crappy road.
Saying that unjustified technical matters which oppose "reality" are excusable in a movie intended for a geeky audience is like saying that it's excusable for the girl to fall for a half-wit jackass who beats on her in a chick-flick.
That would also be "just a movie", but I'd be surprised if many would call it a good one.
You go on to say that you liked it because the computer agreed to live peacefully with everybody in the end, and that you disliked the dialogue in the second movie.
The first two movies reminded me of Goedel's incompleteness theorem. Smith (in the first movie) said that there had been talk of lacking a language sufficient to describe a "perfect" world. In the second movie, I felt that the system had been built in such a way as to allow these flaws in their system to allow it to function anyways. The Oracle existed to help to isolate those who might threaten the system.
You claim that there was too much talking, and that things which weren't justified should be ignored because "it is a movie."
Somehow that doesn't compel me to go watch the third movie.
No, this wasn't for a computer-crime division, or anything meant for the technically savvy. It was intended for normal users -- think secretaries and PHBs, not kiddie-porn and online scam hunters.
Rumor has it that a few years ago when they were constructing a new FBI building in Pittsburgh, one of the FBI bigwhigs wanted to look into getting every computer in the building access through cable modems.
That's right, not shared access from behind a firewall which was connected through a cable modem, but he wanted to have one per system.
I say that this is a rumor because I heard it from an older gentleman who worked for the FBI (a big ham radio fan, as well) over lunch when he and my then-employer were swapping stories of cluelessness, and I'm not sure how close to implementing this setup they actually were. It's amusing nonetheless.
Is the script any more "free" than free packages that depend on non-free software to run?
Yes. The script performs a function and allows others to modify that functionality and redistribute their modifications. It requires no non-free software, and can run on a 100% DFSG-compliant system. The other cannot run without non-free software, period.
If the program is DFSG-compliant, and requires no DFSG-compliant software to function, it belongs in main.
If the program is DFSG-complaint, and cannot run without non-free software, it belongs in contrib.
If the program is not DFSG-compliant, it belongs in non-free.
What the program does is not an issue -- a script which parses and modifies a text file may be adapted to many situations. Since users are free to perform and redistribute these modifications, the script has no place in non-free.
Thanks for the response. The part that I'm not clear about is more the wrapping that will be done -- under Linux, I'd imagine that it wouldn't be the OS calling the printer driver, but some other (user space) code.
I suppose the lack of understanding on my part is due to the fact that Linux in general doesn't have a "driver model" so much as a bunch of scripts which can be used as filters ("drivers", some call them).
Given the lack of a standardized printing system, would it still not be worth the effort to attempt to engineer a standardized print system modelled after Windows?
Hell, actually, I suppose the most relevant question here is, do you know if the function to which you referred is actually implemented by the driver itself, or is it in a higher layer somewhere? I'd imagine that Windows would render in a standard way, and expect as little as possible from each device in order to support the WYSIWYG goals.
The one thing that windows has pretty much always done well is print.
That, and deal with changing color depths and resolutions on-the-fly, but that's another topic.
I appreciate the fact that you're standing up to say that Microsoft did a great job of integrating printing into the functionality of their OS. MS really does work hard at integration, which is why UNIX can often feel like a bag of loose tools. Of course, this is Slashdot, and that's not always a "safe" thing to do......and I'm 23. Not that it matters. But I'm 23. Yeah.
I do not "know too much to learn more." In fact, I have been asking all along for a brief explanation.
I don't code under Windows, and I don't have a feel for the system architecture. Hell, I've never even owned a computer which ran Windows -- the Windows XP system on which I was looking at the printer definition files is actually my girlfriend's laptop.
The point is that there's no point in me trying to decipher just how the GDI relates to every little thing in Windows, or figure out how Windows is architected, because I don't care. You wrote a comment saying that the complexity of the GDI prevents one from being able to easily use Windows components in a non-Windows environment, and made a claim that third-party code could not use the same components as quickly as Windows itself. I replied to say that I didn't see why it wouldn't be possible for other systems to use those components.
Never did I claim to know anything about how Windows' components fit together, because I honestly don't. That's actually why I asked you to explain your assertions.
You've done nothing but avoid justifying your own statements. Whether I'm a kid or a senior citizen, whether I was born in the 70s or the 30s, you haven't justified your statements. You say that you don't think I'd understand, you say that you think I'm not fit for engineering, you say lots of things, but what you don't mention is just what aspect of the interface between Windows and printer drivers is so arcane that using it elsewhere would, for some reason, incur major speed penalties. Yes, you've said "GDI" and "unified driver" as though these phrases were supposed to suddenly trigger some innate knowledge in my mind, but as I've said, I've never written anything substantial for Windows, and I am not familiar with Windows' architecture.
Personally, I don't see what your one line of client code has to do with the driver API. To put it into terms with which I am familiar, it seems to me like describing the protocol used by X clients to communicate to the X server as a way of illustrating the video driver interface -- they both relate to displaying information on the screen, but client <--> server doesn't necessarily map well to server <--> video hardware.
In fact, I would imagine that the line of code which you've supplied maps to some basic function implemented by the driver in a way which is not specific to fonts at all. I know that X clients can send bitmaps to the server, and then refer to these bitmaps by a specific handle rather than transferring the entire image each time. I'd imagine that the call you mentioned is simply a convenience function provided by Windows which would decode font information and send it in a general way to the driver in the same way that one might send any other image data which is likely to be repeated in a way similar to the X protocol feature which I mentioned.
This design would allow driver developers to write drivers which perform basic functions without worrying about writing font handling code which would be better situated in a higher layer of functionality. It makes sense to me that font rendering would be done by general, device-agnostic code, rather than forcing every printer or display driver to handle the nasty details on its own.
But, that runs counter to your assertion, which implied that the interface might not be so clean. Again, this is why I asked for more information. You claimed to know, and I was interested.
I imagine that you'll sit there and think of ways to imply that you're much older and wiser than I am, and more experienced in a research environment, rather than prove that you do have this store of knowledge which you claim to possess.
But, I still challenge you to justify your original assertion -- that the interface between the printer driver and Windows itself is such that nothing will be able to utilize the driver code faster than Windows itself.
Actually, again reading your post ("and or too lazy"?), I am presented evidence of your lack of aptitude for the English language.
I didn't suggest that a program would reverse-engineer anything. I made a hypothesis regarding the text files which Windows' unified driver uses to determine how to speak to a printer.
I'm going to assume that you've actually never worked anything near a research lab, and that you're actually the child here. I somehow picture you sitting in your parents' basement playing RPGs while thinking of ways to avoid the fact that you, in fact, haven't explained anything, and have just deferred to Google.
You've pasted one line of GDI-related code, which didn't even have anything specifically to do with printing. You didn't describe the interface between the definition files and the drivers. And take note -- I haven't been the one going on about how the GDI permeates everything Windows touches.
When you finally graduate high school and maybe attempt to write that first real research paper, you'll be surprised how far that "go do your own research, jeez" attitude will get you. Let me spoil the surprise just a little here -- it won't lead to publication.
And I still challenge you to provide an explanation.
However, as of a few months back, integration wasn't working properly, and after a week of running the client continuously, all I got for my efforts was a large amount of bandwidth consumed, and very slow page access.
I'm all about Freenet, but integration didn't work for me. I'll give it another shot in a few months, but for now I don't have the time to play.
I've invited you several times to justify your assertions, and the closest you've really come is saying "two works: unified driver".
Let me make this painfully easy -- I've asked that you explain your statements. Now, this request presupposes that you possess both an understanding of what you've claimed to be true, and the ability to express yourself in a coherent manner.
There are four possibilities here:
1) You possess neither the requisite knowledge to justify your statements, nor a sufficient command of language to express yourself. 2) You don't have the understanding to justify what you've said, but your grasp of the English language is such that you would be able to explain yourself if you knew what you were talking about. 3) You possess the knowledge to justify your claims, but your communication skills are not quite up to par. 4) You have the knowledge to back up your claims, and the ability to communicate effectively.
Now, given that you have shown ignorance of even basic grammatical constructs, I'm going to assume that #2 and #4 are right out.
Given that you constantly try to force the discussion away from any direction which would require you to actually explain something coherently, I'm going to assume that #3 is probably out as well.
If you don't know enough to back up your claims, that's fine, admit it, and defer to Google. If you cannot communicate clearly enough to explain yourself, admit it, and defer to Google.
I may be misinterpreting what you're saying here, but I don't think you're making a good case for your proposal.
You state:
1) Without government subsidies, nuclear energy would cost much more than using fossil fuels. 2) You would like to see governments "stop subsidizing other forms of energy", which I take to mean forms of energy other than fossil fuels (which you propose be taxed to hell and back).
In other words, you suggest that the government stop helping to make nuclear energy cheaper. You go on to suggest that in order to keep nuclear energy attractive, fossil fuels should be taxed heavily.
So, your whole plan is basically "make everything much more expensive, but make sure that taxation makes the cost of fossil fuels even higher than the cost of nuclear energy".
You say that Republicans won't let this happen. If by "Republicans" you mean "people who don't want to see energy prices skyrocket", then call me a Republican.
I don't know what you're talking about, I don't own an adult.
My point is that the portions of Windows specific to each printer (ie, whatever Windows means when it refers to installing printer-specific "drivers") should be able to be used elsewhere, and you keep babbling about the GDI.
BTW you are correct on one thing, Linux can parse a simple text file. You however are another matter entirely.
Whoa-ho! That's a real knee-slapper there, you sly dog, you!
From what I've seen of the DDK so far, there's NOTHING related to the GDK in the GPD files for my HP printer, only some external references to predefined symbols which are related to printing, and aren't tied to any particular environment.
If someone parsed the GPD files (or their counterparts in PS printer drivers), they could construct the commands necessary to get the printer to print something, which is the goal here.
The goal is NOT to rewrite the GDI with which you are so enamored, the goal is to attempt to use whatever resources are available which would give someone a jump-start with regards to making it easier to print from Linux and other UNIX-ish environments.
The funny part here is that you claim to have tons of experience and knowledge in this realm, but so far you've posted one line of code which could have been copied from anywhere, a link to the Windows 98 DDK (I seem to recall you saying something about drivers having changed considerably since Win98), and a lot of drivel about "hmmm GDI blah blah GDI beable GDI Xwindows i love GDI MS yeah".
I'll bet that one could use Windows' "print to file" feature, produce a raw data file suitable for sending directly to the printer, and with nothing more than the GPD files and a good hex viewer figure out what the printer is being instructed to do, with zero knowledge of the GDI.
Once the file has been reverse-engineered, it's time to think about how an equivalent stream could be constructed given the GDI files and the data to be printed.
My challenge to you is this: stop posturing and explain just how a text file which explains how to get a printer to do things like set margins, choose a paper size, select dithering style, etc. depends on the GDI.
The more I look into Windows printer drivers, the more it turns out that you're a wannabe know-it-all fuckwit.
It turns out that most Windows "printer drivers" are text files which contain definitions telling Windows things like which paper sizes the printer supports, and how to tell the printer what size margins you'd like.
In fact, basically what you've been telling us is that you don't think that Linux can parse a text file with printer commands as quickly as Windows can parse a text file with printer commands.
I don't see anything GDI-related in the printer definition files related to my HP DeskJet 895Cxi. In fact, it's basically the same stuff which was included in the owner's manual for my old DeskJet 500C, albeit in a more structured (read: machine-parseable) format.
Tricks are used, sure, but I'd be really surprised if most devices didn't support basic bitmap draw operations on some level. Even if a driver supported hardware-assisted rendering of certain objects, there's nothing that makes use of those code paths required.
Faster, perhaps, but not required, and features could be added incrementally which would eventually fill in the rest of the functionality.
Further, we're talking about printer drivers here, not hardware-accelerated 3D drivers with shaders and other nifty features. As I understand it, most higher-quality printers support PCL or PS, and would work with Linux anyways, sans drivers. Lower-quality printers are generally more limited by the speed of hardware than the CPU speed of the machine requesting a printout.
One could make a case that without certain features, more data would be sent across the wire (parallel cable, USB, etc.), adding a bottleneck. However, I don't think it's as bad as the parent poster would have everyone believe. You've summarized my point quite well -- that "[t]he GDI isn't the driver interface, there's some other slightly simpler interface."
I have a feeling that if the parent poster really did have evidence that the GDI mapped quite directly to the interface presented to the printer drivers already, he's probably drop his posturing attitude and explain himself further.
As it is, his "That's the way it is and you must be an idiot" attitude isn't productive.
Yes, I do code, although I've never done anything more than trivial GUI programs under Windows.
You assert that the API exported to the programs themselves is quite complex, and would require a hell of a lot to emulate/replace.
That may be true -- however, what about the API seen by the driver itself?
From what I understand (and feel free to correct me here), Windows programs can supposedly draw in the same way to any (FSVO "any") display device regardless of whether it's a printer or a display.
This leads me to think that somewhere, drawing requests made by an application are translated from higher-level commands down to primitives.
You refer to the Windows GDI. I would imagine that most of the drawing requests are translated to much simpler commands before they ever hit the driver. Not "Draw this text, using this typeface, at this location, in this color", but "Draw this pixel in this color."
Are you familiar with the interface between the drivers and the OS, or are you just making assumptions based on the interactions between the application programs and the Windows GDI? Do you have any links to Windows driver development resources?
This is something in which I've been interested previously (although more in reference to filesystem drivers), but I haven't been able to find a decent online reference.
I should have made it more clear that in saying that drivers are basically libraries, I was referring to printer drivers, not (for instance) OpenGL drivers.
I'm basically saying that if a given interface to a printer driver is defined, it should be possible for a program coded to that interface to interact with that program in an efficient manner.
To play your game of assuming knowledge of which I have no direct evidence, given the fact that you don't realize that it's a windowing system called "X", not "Xwindows", I believe you probably aren't qualified to say what may or may not be possible.
Stupid jabs aside, you haven't explained why you are under the impression that one couldn't write a loader which would open the driver file, locate the relevant code segments, load them into memory, and set up a jump table to the relevant portions. Certain Windows functionality would have to be emulated, but basically you'd be writing a loader which would export the Windows driver's functionality. I'm not talking about a translation layer, which you seem to think is necessary, because I'm not implicitly assuming that whatever program managed printing (such as lpr, etc) would be translating anything.
Windows places abstraction between the driver and the program. This loader would also place abstraction between the driver and the program, such as exporting a/dev-style interface, but again I see no reason why the Linux-based abstraction is necessarily slower than the Windows-based abstraction.
In fact, strictly speaking in the domain of supporting printer drivers, I'd be quite surprised if the code to support Windows drivers under Linux weren't much more efficient, because of the more focused goal of supporting printing, as opposed to supporting everything that the Windows GDI entails.
As far as me having an "agenda", I don't know what you're talking about. I'm simply saying that I don't understand your assumption that a Windows printer driver cannot be efficiently used by another OS which exports a similar interface, and you haven't really offered an explanation other than expressing your assumption that many layers of translation and indirection are necessary.
I'm also confused as to the nature of this assumption.
Device drivers are modules. Think of them as dynamic libraries, if you will. These libraries are designed in such a way that they can be used by several different programs.
Programs which can use these libraries include Windows 98, Win2k, and Windows XP.
Why are you so sure that one program cannot be adapted to use these libraries in a way that is just as fast as another program using them?
To use an analogy, GTK is an interface library which was designed to be used by GIMP. By your logic, since GTK was designed to be used by a specific image manipulation program (GIMP), I cannot possibly write an image manipulation program which uses GTK yet is as fast as or faster than GIMP.
"Happy Birthday" certainly is owned, which is why most restaurants (especially chains with large corporations behind them) don't sing it to their patrons, instead concocting some stupid other song.
Furthermore, ASCAP long ago decided to force the Girl Scouts of America to pay for the right to sing copyrighted songs around campfires, "Happy Birthday" included. A huge fuss was raised, and rather than stand their ground and continue to ask for the normal, full-priced licensing fees, they decided to lick their wounds and settle for a small token fee (something like $1 per year).
The Girl Scouts of America now pays the protection money to keep ASCAP's lawyers off of their backs, and ASCAP gets to say that even teenage girls with braces and an acoustic guitar have to pay to keep the thugs away.
The long and short of it, though, is that "Happy Birthday" is not public domain. A quick Google search would have told you that.
For an example of the effects of this, go to the Olive Garden (or some other chain restaurant) with someone and tell the wait[er|ress] that it's your friend's birthday.
Timothy writes "If your answer is Unique Stories, you're plain wrong. It's DUPES, a Canadian method of post generation that can be customized for any large-scale media systems. According to a popular geek news site, it is used by more than 300 story submissions each year. The article looks at the competition in this market, notably Michael, known for not even reading submissions before posting to the homepage. This last effort could lead to the eDUPE method, an encryption method that offers secure post submission across wireless networks and the Internet. One thing is sure for this market: the future is definitively open-source. This overview contains more details and external references.
Slashdot Mirror
I agree to some extent. However, I would imagine that most people's views on Israel are less informed than you think -- I'd wager that the average American doesn't know what country Israel is in conflict with.
Americans don't seem to know or care much about Israel at all. "America" reportedly has an opinion on the matter, but that's the government, not the population.
On one hand, many people do not seek outside news sources. On the other hand, they are not nearly as widely available as localized news sources in America. Other countries' media outlets are more well-connected. I would doubt that this fact is a result of specific action by the populations of other countries, but more a result of geographic factors.
In the media, infrequently asked questions include:
Okie, time for work. Have a nice day, everyone!
There is no ego trip among many of the citizens. There is massive ignorance of real international affairs by the media, but we American citizens don't control American media.
I'll tell you what. Since you're an expert on all things wrong with America, why don't you provide examples of us Americans following our government's every whim?
Try to back it up with actual facts where possible.
Okay, but how do his "powers" carry over into the "real world"?
It was my impression from having seen the first two episodes that Neo was able to step outside of the rules of the Matrix because the system was designed to be believable by its occupants. As a result, it would allow Neo to do what he believed he could do. Since he knew that the system's rules didn't apply to him, the Matrix did his bidding.
When you say, "his powers are not limited to just the matrix", to which powers are you referring? His powers within the Matrix are limited to presenting his set of beliefs to the system (that he could fly, etc.) and allowing the system to present a reality to him which matched those beliefs.
Your claim that Neo's power to know that the Matrix is fake extends to the real world. That I can believe.
However, how does his knowing-that-the-Matrix-is-fake allow him to manipulate robots in the real world?
The parent poster basically said that he wasn't sure how Smith entered a real person. You say, "I just kind of look at it as he found a way to the subway station... and then entered the real world."
In short:
Parent> I don't see how he entered the real world.
You> He found a subway station, then entered the real world.
The parent wasn't questioning Smith's ability to locate a subway station (in fact, he was in a subway station in the original movie), but wondered how Smith (a piece of software) could control a human.
That's what the parent was complaining about! Playing the "it's just a movie" card when somebody complains about plot holes doesn't excuse the fact that there are holes in the plot.
Again, in dialogue form:
Person> That road is full of potholes, and my car's suspension is bad from driving on it! What crappy roads Pennsylvania has!
Other person> I'll agree that having your car suffer damage is disappointing, but it is just a road.
Person> Whatever. It's still a crappy road.
Saying that unjustified technical matters which oppose "reality" are excusable in a movie intended for a geeky audience is like saying that it's excusable for the girl to fall for a half-wit jackass who beats on her in a chick-flick.
That would also be "just a movie", but I'd be surprised if many would call it a good one.
You go on to say that you liked it because the computer agreed to live peacefully with everybody in the end, and that you disliked the dialogue in the second movie.
The first two movies reminded me of Goedel's incompleteness theorem. Smith (in the first movie) said that there had been talk of lacking a language sufficient to describe a "perfect" world. In the second movie, I felt that the system had been built in such a way as to allow these flaws in their system to allow it to function anyways. The Oracle existed to help to isolate those who might threaten the system.
You claim that there was too much talking, and that things which weren't justified should be ignored because "it is a movie."
Somehow that doesn't compel me to go watch the third movie.
No, this wasn't for a computer-crime division, or anything meant for the technically savvy. It was intended for normal users -- think secretaries and PHBs, not kiddie-porn and online scam hunters.
Rumor has it that a few years ago when they were constructing a new FBI building in Pittsburgh, one of the FBI bigwhigs wanted to look into getting every computer in the building access through cable modems.
That's right, not shared access from behind a firewall which was connected through a cable modem, but he wanted to have one per system.
I say that this is a rumor because I heard it from an older gentleman who worked for the FBI (a big ham radio fan, as well) over lunch when he and my then-employer were swapping stories of cluelessness, and I'm not sure how close to implementing this setup they actually were. It's amusing nonetheless.
If the program is DFSG-compliant, and requires no DFSG-compliant software to function, it belongs in main.
If the program is DFSG-complaint, and cannot run without non-free software, it belongs in contrib.
If the program is not DFSG-compliant, it belongs in non-free.
What the program does is not an issue -- a script which parses and modifies a text file may be adapted to many situations. Since users are free to perform and redistribute these modifications, the script has no place in non-free.
I suppose the lack of understanding on my part is due to the fact that Linux in general doesn't have a "driver model" so much as a bunch of scripts which can be used as filters ("drivers", some call them).
Given the lack of a standardized printing system, would it still not be worth the effort to attempt to engineer a standardized print system modelled after Windows?
Hell, actually, I suppose the most relevant question here is, do you know if the function to which you referred is actually implemented by the driver itself, or is it in a higher layer somewhere? I'd imagine that Windows would render in a standard way, and expect as little as possible from each device in order to support the WYSIWYG goals.
That, and deal with changing color depths and resolutions on-the-fly, but that's another topic.
I appreciate the fact that you're standing up to say that Microsoft did a great job of integrating printing into the functionality of their OS. MS really does work hard at integration, which is why UNIX can often feel like a bag of loose tools. Of course, this is Slashdot, and that's not always a "safe" thing to do...
I do not "know too much to learn more." In fact, I have been asking all along for a brief explanation.
I don't code under Windows, and I don't have a feel for the system architecture. Hell, I've never even owned a computer which ran Windows -- the Windows XP system on which I was looking at the printer definition files is actually my girlfriend's laptop.
The point is that there's no point in me trying to decipher just how the GDI relates to every little thing in Windows, or figure out how Windows is architected, because I don't care. You wrote a comment saying that the complexity of the GDI prevents one from being able to easily use Windows components in a non-Windows environment, and made a claim that third-party code could not use the same components as quickly as Windows itself. I replied to say that I didn't see why it wouldn't be possible for other systems to use those components.
Never did I claim to know anything about how Windows' components fit together, because I honestly don't. That's actually why I asked you to explain your assertions.
You've done nothing but avoid justifying your own statements. Whether I'm a kid or a senior citizen, whether I was born in the 70s or the 30s, you haven't justified your statements. You say that you don't think I'd understand, you say that you think I'm not fit for engineering, you say lots of things, but what you don't mention is just what aspect of the interface between Windows and printer drivers is so arcane that using it elsewhere would, for some reason, incur major speed penalties. Yes, you've said "GDI" and "unified driver" as though these phrases were supposed to suddenly trigger some innate knowledge in my mind, but as I've said, I've never written anything substantial for Windows, and I am not familiar with Windows' architecture.
Personally, I don't see what your one line of client code has to do with the driver API. To put it into terms with which I am familiar, it seems to me like describing the protocol used by X clients to communicate to the X server as a way of illustrating the video driver interface -- they both relate to displaying information on the screen, but client <--> server doesn't necessarily map well to server <--> video hardware.
In fact, I would imagine that the line of code which you've supplied maps to some basic function implemented by the driver in a way which is not specific to fonts at all. I know that X clients can send bitmaps to the server, and then refer to these bitmaps by a specific handle rather than transferring the entire image each time. I'd imagine that the call you mentioned is simply a convenience function provided by Windows which would decode font information and send it in a general way to the driver in the same way that one might send any other image data which is likely to be repeated in a way similar to the X protocol feature which I mentioned.
This design would allow driver developers to write drivers which perform basic functions without worrying about writing font handling code which would be better situated in a higher layer of functionality. It makes sense to me that font rendering would be done by general, device-agnostic code, rather than forcing every printer or display driver to handle the nasty details on its own.
But, that runs counter to your assertion, which implied that the interface might not be so clean. Again, this is why I asked for more information. You claimed to know, and I was interested.
I imagine that you'll sit there and think of ways to imply that you're much older and wiser than I am, and more experienced in a research environment, rather than prove that you do have this store of knowledge which you claim to possess.
But, I still challenge you to justify your original assertion -- that the interface between the printer driver and Windows itself is such that nothing will be able to utilize the driver code faster than Windows itself.
Correction:
Actually, after reading your post ("and or too lazy"?), I am presented with evidence of your lack of aptitude for the English language
Yes, some of us actually care enough about correctness to admit mistakes and correct them.
Yeah, that must be it.
Actually, again reading your post ("and or too lazy"?), I am presented evidence of your lack of aptitude for the English language.
I didn't suggest that a program would reverse-engineer anything. I made a hypothesis regarding the text files which Windows' unified driver uses to determine how to speak to a printer.
I'm going to assume that you've actually never worked anything near a research lab, and that you're actually the child here. I somehow picture you sitting in your parents' basement playing RPGs while thinking of ways to avoid the fact that you, in fact, haven't explained anything, and have just deferred to Google.
You've pasted one line of GDI-related code, which didn't even have anything specifically to do with printing. You didn't describe the interface between the definition files and the drivers. And take note -- I haven't been the one going on about how the GDI permeates everything Windows touches.
When you finally graduate high school and maybe attempt to write that first real research paper, you'll be surprised how far that "go do your own research, jeez" attitude will get you. Let me spoil the surprise just a little here -- it won't lead to publication.
And I still challenge you to provide an explanation.
Aye, there are many misconceptions about Freenet.
However, as of a few months back, integration wasn't working properly, and after a week of running the client continuously, all I got for my efforts was a large amount of bandwidth consumed, and very slow page access.
I'm all about Freenet, but integration didn't work for me. I'll give it another shot in a few months, but for now I don't have the time to play.
I've invited you several times to justify your assertions, and the closest you've really come is saying "two works: unified driver".
Let me make this painfully easy -- I've asked that you explain your statements. Now, this request presupposes that you possess both an understanding of what you've claimed to be true, and the ability to express yourself in a coherent manner.
There are four possibilities here:
1) You possess neither the requisite knowledge to justify your statements, nor a sufficient command of language to express yourself.
2) You don't have the understanding to justify what you've said, but your grasp of the English language is such that you would be able to explain yourself if you knew what you were talking about.
3) You possess the knowledge to justify your claims, but your communication skills are not quite up to par.
4) You have the knowledge to back up your claims, and the ability to communicate effectively.
Now, given that you have shown ignorance of even basic grammatical constructs, I'm going to assume that #2 and #4 are right out.
Given that you constantly try to force the discussion away from any direction which would require you to actually explain something coherently, I'm going to assume that #3 is probably out as well.
If you don't know enough to back up your claims, that's fine, admit it, and defer to Google. If you cannot communicate clearly enough to explain yourself, admit it, and defer to Google.
Just don't claim that you've explained yourself.
Hah! Good point ;)
I may be misinterpreting what you're saying here, but I don't think you're making a good case for your proposal.
You state:
1) Without government subsidies, nuclear energy would cost much more than using fossil fuels.
2) You would like to see governments "stop subsidizing other forms of energy", which I take to mean forms of energy other than fossil fuels (which you propose be taxed to hell and back).
In other words, you suggest that the government stop helping to make nuclear energy cheaper. You go on to suggest that in order to keep nuclear energy attractive, fossil fuels should be taxed heavily.
So, your whole plan is basically "make everything much more expensive, but make sure that taxation makes the cost of fossil fuels even higher than the cost of nuclear energy".
You say that Republicans won't let this happen. If by "Republicans" you mean "people who don't want to see energy prices skyrocket", then call me a Republican.
"if your adult"
I don't know what you're talking about, I don't own an adult.
My point is that the portions of Windows specific to each printer (ie, whatever Windows means when it refers to installing printer-specific "drivers") should be able to be used elsewhere, and you keep babbling about the GDI.
BTW you are correct on one thing, Linux can parse a simple text file. You however are another matter entirely.
Whoa-ho! That's a real knee-slapper there, you sly dog, you!
From what I've seen of the DDK so far, there's NOTHING related to the GDK in the GPD files for my HP printer, only some external references to predefined symbols which are related to printing, and aren't tied to any particular environment.
If someone parsed the GPD files (or their counterparts in PS printer drivers), they could construct the commands necessary to get the printer to print something, which is the goal here.
The goal is NOT to rewrite the GDI with which you are so enamored, the goal is to attempt to use whatever resources are available which would give someone a jump-start with regards to making it easier to print from Linux and other UNIX-ish environments.
The funny part here is that you claim to have tons of experience and knowledge in this realm, but so far you've posted one line of code which could have been copied from anywhere, a link to the Windows 98 DDK (I seem to recall you saying something about drivers having changed considerably since Win98), and a lot of drivel about "hmmm GDI blah blah GDI beable GDI Xwindows i love GDI MS yeah".
I'll bet that one could use Windows' "print to file" feature, produce a raw data file suitable for sending directly to the printer, and with nothing more than the GPD files and a good hex viewer figure out what the printer is being instructed to do, with zero knowledge of the GDI.
Once the file has been reverse-engineered, it's time to think about how an equivalent stream could be constructed given the GDI files and the data to be printed.
My challenge to you is this: stop posturing and explain just how a text file which explains how to get a printer to do things like set margins, choose a paper size, select dithering style, etc. depends on the GDI.
The more I look into Windows printer drivers, the more it turns out that you're a wannabe know-it-all fuckwit.
It turns out that most Windows "printer drivers" are text files which contain definitions telling Windows things like which paper sizes the printer supports, and how to tell the printer what size margins you'd like.
In fact, basically what you've been telling us is that you don't think that Linux can parse a text file with printer commands as quickly as Windows can parse a text file with printer commands.
I don't see anything GDI-related in the printer definition files related to my HP DeskJet 895Cxi. In fact, it's basically the same stuff which was included in the owner's manual for my old DeskJet 500C, albeit in a more structured (read: machine-parseable) format.
Any comments, wiseass?
I appreciate your response.
Tricks are used, sure, but I'd be really surprised if most devices didn't support basic bitmap draw operations on some level. Even if a driver supported hardware-assisted rendering of certain objects, there's nothing that makes use of those code paths required.
Faster, perhaps, but not required, and features could be added incrementally which would eventually fill in the rest of the functionality.
Further, we're talking about printer drivers here, not hardware-accelerated 3D drivers with shaders and other nifty features. As I understand it, most higher-quality printers support PCL or PS, and would work with Linux anyways, sans drivers. Lower-quality printers are generally more limited by the speed of hardware than the CPU speed of the machine requesting a printout.
One could make a case that without certain features, more data would be sent across the wire (parallel cable, USB, etc.), adding a bottleneck. However, I don't think it's as bad as the parent poster would have everyone believe. You've summarized my point quite well -- that "[t]he GDI isn't the driver interface, there's some other slightly simpler interface."
I have a feeling that if the parent poster really did have evidence that the GDI mapped quite directly to the interface presented to the printer drivers already, he's probably drop his posturing attitude and explain himself further.
As it is, his "That's the way it is and you must be an idiot" attitude isn't productive.
Yes, I do code, although I've never done anything more than trivial GUI programs under Windows.
You assert that the API exported to the programs themselves is quite complex, and would require a hell of a lot to emulate/replace.
That may be true -- however, what about the API seen by the driver itself?
From what I understand (and feel free to correct me here), Windows programs can supposedly draw in the same way to any (FSVO "any") display device regardless of whether it's a printer or a display.
This leads me to think that somewhere, drawing requests made by an application are translated from higher-level commands down to primitives.
You refer to the Windows GDI. I would imagine that most of the drawing requests are translated to much simpler commands before they ever hit the driver. Not "Draw this text, using this typeface, at this location, in this color", but "Draw this pixel in this color."
Are you familiar with the interface between the drivers and the OS, or are you just making assumptions based on the interactions between the application programs and the Windows GDI? Do you have any links to Windows driver development resources?
This is something in which I've been interested previously (although more in reference to filesystem drivers), but I haven't been able to find a decent online reference.
I should have made it more clear that in saying that drivers are basically libraries, I was referring to printer drivers, not (for instance) OpenGL drivers.
/dev-style interface, but again I see no reason why the Linux-based abstraction is necessarily slower than the Windows-based abstraction.
I'm basically saying that if a given interface to a printer driver is defined, it should be possible for a program coded to that interface to interact with that program in an efficient manner.
To play your game of assuming knowledge of which I have no direct evidence, given the fact that you don't realize that it's a windowing system called "X", not "Xwindows", I believe you probably aren't qualified to say what may or may not be possible.
Stupid jabs aside, you haven't explained why you are under the impression that one couldn't write a loader which would open the driver file, locate the relevant code segments, load them into memory, and set up a jump table to the relevant portions. Certain Windows functionality would have to be emulated, but basically you'd be writing a loader which would export the Windows driver's functionality. I'm not talking about a translation layer, which you seem to think is necessary, because I'm not implicitly assuming that whatever program managed printing (such as lpr, etc) would be translating anything.
Windows places abstraction between the driver and the program. This loader would also place abstraction between the driver and the program, such as exporting a
In fact, strictly speaking in the domain of supporting printer drivers, I'd be quite surprised if the code to support Windows drivers under Linux weren't much more efficient, because of the more focused goal of supporting printing, as opposed to supporting everything that the Windows GDI entails.
As far as me having an "agenda", I don't know what you're talking about. I'm simply saying that I don't understand your assumption that a Windows printer driver cannot be efficiently used by another OS which exports a similar interface, and you haven't really offered an explanation other than expressing your assumption that many layers of translation and indirection are necessary.
I'm also confused as to the nature of this assumption.
How so?
Device drivers are modules. Think of them as dynamic libraries, if you will. These libraries are designed in such a way that they can be used by several different programs.
Programs which can use these libraries include Windows 98, Win2k, and Windows XP.
Why are you so sure that one program cannot be adapted to use these libraries in a way that is just as fast as another program using them?
To use an analogy, GTK is an interface library which was designed to be used by GIMP. By your logic, since GTK was designed to be used by a specific image manipulation program (GIMP), I cannot possibly write an image manipulation program which uses GTK yet is as fast as or faster than GIMP.
To me, this is faulty thinking.
"Happy Birthday" certainly is owned, which is why most restaurants (especially chains with large corporations behind them) don't sing it to their patrons, instead concocting some stupid other song.
Furthermore, ASCAP long ago decided to force the Girl Scouts of America to pay for the right to sing copyrighted songs around campfires, "Happy Birthday" included. A huge fuss was raised, and rather than stand their ground and continue to ask for the normal, full-priced licensing fees, they decided to lick their wounds and settle for a small token fee (something like $1 per year).
The Girl Scouts of America now pays the protection money to keep ASCAP's lawyers off of their backs, and ASCAP gets to say that even teenage girls with braces and an acoustic guitar have to pay to keep the thugs away.
The long and short of it, though, is that "Happy Birthday" is not public domain. A quick Google search would have told you that.
For an example of the effects of this, go to the Olive Garden (or some other chain restaurant) with someone and tell the wait[er|ress] that it's your friend's birthday.
Timothy writes "If your answer is Unique Stories, you're plain wrong. It's DUPES, a Canadian method of post generation that can be customized for any large-scale media systems. According to a popular geek news site, it is used by more than 300 story submissions each year. The article looks at the competition in this market, notably Michael, known for not even reading submissions before posting to the homepage. This last effort could lead to the eDUPE method, an encryption method that offers secure post submission across wireless networks and the Internet. One thing is sure for this market: the future is definitively open-source. This overview contains more details and external references.