3) Managed code avoids DLL hell: the GAC and side-by-side execution ensure that programs will continue to run on versions of libraries that they are designed to support, since minor/major version upgraded files will not be fed to these applications (although revisions still can for bug fixing reasons.)
Sorry, many of those slightly-incompatible variants of Windows DLLs that break applications were also just introduced for "bug fixing reasons" (different versions can have different filenames). You can't ensure binary compatibility automatically. "DLL hell" is an organizational problem, not a technical one. And what is the.NET equivalent to LD_LIBRARY_PATH?
The XML primarily allows you to specify the layout of widgets on your form (whatever the render happens to be: Windows.Forms or Areo's Canvas class). Sure, it's nice to be able to define this in a standard format, but I'm having trouble figuring out what's the big deal?
AFAICS, it's basically a rip-off of the persistence mechanisms used in e.g. NextSTEP's or Delphi's UI frameworks. The idea has also been adopted in Java's "Long-Term Persistence for JavaBeans" facility, which is part of the java.beans package in JDK 1.4+.
The XAML files (as well as Delphi's.form files or the XML written by Java's bean framework) contain declarative descriptions of the object(widget) tree that makes up the form/window/page described by the XAML/XML/.form file. A tag name in an XAML is just the class name of the corresponding widget's class, the attributes inside the tag hold property values. The java.beans.XMLEncoder class in the JDK produces such a similar XML representation file for JavaBeans-based GUI elements and JavaBeans in general.
The idea is to have those files generated by a GUI editor at design time, then read them back in and recreate the corresponding window/form/etc. at runtime.
Now, XML is being used to specify the look and feel down to the last pixel.
Not necessarily. You can use "panels" which arrange their child controls in a more flexible manner.
By default, ASP.NET generates HTML that is located by absolute position, and text is specified with a particular font in a particular size...
Well, that's unfortunate, but certainly not a technical necessity...
That also means that the UI designer is decoupled from the programmers to a degree. Want to change the interface, make it better? Don't need to wake the programmer up. Linux could have had that instead of the traditional hardcoding that KDE and GNOME presently presents.
How are highly dynamic classes like Python's or CLOS's implemented? Or Lisp macros? I somehow doubt that you can implement anything other than single-dispatch class-based languages on a single-dispatch class-based runtime like the CLR _efficiently_. Of course, you can in theory implement any turing-complete language on any turing-complete runtime, but if it were so easy to do this efficiently and without semantic losses, it would have been done a long time ago.
Does one have to implement *all* things mentioned in the patent's 20 "claims" at the same time in order to "infringe" the patent? Or is it sufficient to implement *any* of them?
And start appending '/1', '/2' and so on if you have multiple burners.
Hmm, this doesn't look consistent to me at all... There seem to be half a dozen naming schemes for naming SCSI devices? What if you want hardware-independent, symbolic names for your devices? When using device nodes, you just create symlinks...
Mac OS X has kernel support for sending generic SCSI commands to a particular device. For non-Mac OS X, imagine if you could open a regular/dev/sr device node and do an ioctl to access the generic SCSI interface, but only to that device. (And there's no reason why an ATAPI device couldn't give you the same thing; after all, ATAPI is basically SCSI over ATA.)
Actually, I like Unix's universal naming scheme, namely "everything is a file", and consider any other approach for accessing devices a misfeature (at least on Unix-like systems):-)
The issue you mentioned (cdrecord must be SUID root) is just part of the problem. cdrecord doesn't use device nodes which you could apply owner and group rights to, and thus must run with root privileges, re-implementing all security checks normally done by the kernel.
I don't know where the submittor is going saying that PicoGUI has given up on X11 compatibility -- It has a native X11 output driver with root window support! AFAIK, it calls Xlib directly.
Quite obviously, he was talking about X11/Xlib compatibility in the client-side APIs.
In the second case, you want to speak directly to the CD recorder in its native language. That's what the SCSI generic device nodes are for. The program is telling the kernel to get out of the way, because it knows how to speak the device's protocol.
Now what are those SCSI IDs in the dev= parameters for? Why are they needed? What you say seems to imply that accessing the sg device node should be sufficient. Why do I have to say "dev=x,y,z" instead of "dev=/dev/sgx"?
except for a few ioctl quirks, ide and scsi devices are the same
SCSI too? I always have to fiddle with strange SCSI IDs directly in userspace. I never understood what part of the CD burner's functionality is accessed through the device node, and what part is accessed using those strange dev= parameters to cdrecord. I wonder why this can't be dealt with in a more unixish way, i.e. using a device node and bunch of ioctls alone.
That said, I also don't know what this "HAL" thing is supposed to be useful for.
God (the one that most people in the world pray to) NEVER intended us to live this long.
If you look at the statistics more closely, you'll probably notice that improved hygienic conditions have increased the average life expectancy more than all medical advantages ever made combined. Life expectancy 200yrs ago was 45 or so, today it's 80, but the standard deviation was much higher then than it is now (that is, there were *many* more 90-year-olds 200yrs ago than there are 160-year-olds today).
This means that "god" probably never intended us to die at 40, it's just that these days more people reach their "pre-defined" life expectancy instead of being wiped out by some minor unpleasantness long before their time has run out.
As I was saying, it amounts to just the opposite of capitalism. I'm not against people wanting to earn money, I'm against the crazy software patent laws enabling them to do it in anti-competitive, *socialist* ways.
He declared the current state of things then as a "hodgepodge", and it still is today (EJB vs. NET vs. DCOM vs. SOAP vs. agent archs). He claimed he would provide free licenses to anyone who would cooperate.
[...]
the University of California patent will be used to encourage the acceptance of a standard API for Web-based interactive applications, preventing the development of a VHS/ Beta-style "API war" between Microsoft, Netscape, Sun, and the like. We are not asking browser companies to pay royalties for developing browsers that can run applets. Rather, we are only requiring that they adhere to a standard "Web-API" that will be defined by a consortium of Eolas licensees...
That's the same crap as can be found e.g. here.
I.e. "use software patents to regulate competition and enforce standards". You might as well opt for introducing socialism, with the patent office becoming the ruling communist party, and M$, Sun, IBM, and, of course, Eolas, becoming state-approved monopolies.
If the guy honestly believes that he does the software industry as a whole any good by forcing it to adhere to a single "technology" that tries to put EJBs,.NET, DCOM, SOAP, agents, browser plugins and whatnot under one hood, he's a complete lunatic.
But of course, he doesn't mean anything he says. He wants to squeeze as much money as possible out of the patent system without looking too much like a bad boy, and that's about it.
It would be surprising if someone at MS has not thought of this. And just wait, MS may now be able to buy Macromedia at a lower price.
What's more, MS could more easily "persuade" people to switch to the ASP.NET client-side components (which are apparently not covered by the patent) in order to retain the "convenient user experience" they're accustomed to...
If Microsoft owned the patent, IE wouldn't need changes, and the bulk of web pages wouldn't need editing. Then Microsoft could sue AOL (or anyone connected to Mozilla) to destroy the #2 web browser. Apple would be next- they'd have no choice but to beg for the return of Mac IE.
It may well be that they deem it cleverer to "lose" this case, thereby eliminating, among others, *Flash*, *Quicktime, the *Acrobat Reader Plugin*, and *Java Applets* from any and all browsers, and then force ASP.NET (including components running conveniently on the client, which works in IE only) down everyone's throat.
And of course.. what's the betting that OpenOffice can actually use a standard Windows DRM/IRM API at some point to unencrypt documents based on their Windows 2003 Server authentication and signature key?
Please stop posting irrelevant links and tell us how M$ could possibly make those APIs publicly available and still retain all those "document expiration" features.
2) Will Microsoft make any encoding APIs freely available to the public for 3rd party applications to open and use those files?
They can't, because if they did, anybody could write software that reads those files and converts them to whatever format it wishes, thereby circumventing those nifty "document self-destroys tomorrow at 09:30 PM" features.
Looks like M$ is looking for new arguments to make developers pay licenses for their APIs.
As for "competing products" not being able to read these secured documents, well that's the whole point right?
Um, no it is not. The point that unauthorized users shouldn't be able to read the documents. Competing products should be able to read them, provided they know the required keys and can access the DRM server. This requires that MS documents the encryption format. Just as GnuPG etc do.
filesystem namespace, mount tables etc. are per-process, not global
(really) everything-is-a-file, including
network interfaces, sockets
display server backend, i.e. one {/dev/bitblt,/dev/mouse,/dev/cons} set; the server re-exports one disjunct such set to each client (which means that the server may be run as a client of itself)
a single generic protocol (9P) for exporting files over the network. Network transparency of all kinds of services (e.g. the display server) is achieved by exporting the relevant files over the net via 9P
Re:Okay but
on
GTK+ TTY Port
·
· Score: 4, Informative
GDK pixmaps
Judging from the screenshots, those just don't get rendered at all. Generally, the mapping algorithm to character cells seems to be quite smart though...
Galeon used to be an example of how an Open Source Product can be better than proprietary one (i.e. Opera). Now it's just pathetic. One more reason to dislike anyting GNOME-related (and I used to run Galeon from KDE).
I agree. The major problem with Galeon is that it is a GNOME program instead of a simple GTK one. I really don't know why they chose to do this...
Slashdot Mirror
Sorry, many of those slightly-incompatible variants of Windows DLLs that break applications were also just introduced for "bug fixing reasons" (different versions can have different filenames). You can't ensure binary compatibility automatically. "DLL hell" is an organizational problem, not a technical one. And what is the .NET equivalent to LD_LIBRARY_PATH?
AFAICS, it's basically a rip-off of the persistence mechanisms used in e.g. NextSTEP's or Delphi's UI frameworks. The idea has also been adopted in Java's "Long-Term Persistence for JavaBeans" facility, which is part of the java.beans package in JDK 1.4+.
The XAML files (as well as Delphi's .form files or the XML written by Java's bean framework) contain declarative descriptions of the object(widget) tree that makes up the form/window/page described by the XAML/XML/.form file. A tag name in an XAML is just the class name of the corresponding widget's class, the attributes inside the tag hold property values. The java.beans.XMLEncoder class in the JDK produces such a similar XML representation file for JavaBeans-based GUI elements and JavaBeans in general.
The idea is to have those files generated by a GUI editor at design time, then read them back in and recreate the corresponding window/form/etc. at runtime.
Now, XML is being used to specify the look and feel down to the last pixel.
Not necessarily. You can use "panels" which arrange their child controls in a more flexible manner.
By default, ASP.NET generates HTML that is located by absolute position, and text is specified with a particular font in a particular size...
Well, that's unfortunate, but certainly not a technical necessity...
You know about Glade, don't you?
How are highly dynamic classes like Python's or CLOS's implemented? Or Lisp macros? I somehow doubt that you can implement anything other than single-dispatch class-based languages on a single-dispatch class-based runtime like the CLR _efficiently_. Of course, you can in theory implement any turing-complete language on any turing-complete runtime, but if it were so easy to do this efficiently and without semantic losses, it would have been done a long time ago.
Does one have to implement *all* things mentioned in the patent's 20 "claims" at the same time in order to "infringe" the patent? Or is it sufficient to implement *any* of them?
dev=IOCompactDiscServices
dev=IODVDServices
And start appending '/1', '/2' and so on if you have multiple burners.
Hmm, this doesn't look consistent to me at all... There seem to be half a dozen naming schemes for naming SCSI devices? What if you want hardware-independent, symbolic names for your devices? When using device nodes, you just create symlinks...
Mac OS X has kernel support for sending generic SCSI commands to a particular device. For non-Mac OS X, imagine if you could open a regular /dev/sr device node and do an ioctl to access the generic SCSI interface, but only to that device. (And there's no reason why an ATAPI device couldn't give you the same thing; after all, ATAPI is basically SCSI over ATA.)
Actually, I like Unix's universal naming scheme, namely "everything is a file", and consider any other approach for accessing devices a misfeature (at least on Unix-like systems) :-)
The issue you mentioned (cdrecord must be SUID root) is just part of the problem. cdrecord doesn't use device nodes which you could apply owner and group rights to, and thus must run with root privileges, re-implementing all security checks normally done by the kernel.
Quite obviously, he was talking about X11/Xlib compatibility in the client-side APIs.
Now what are those SCSI IDs in the dev= parameters for? Why are they needed? What you say seems to imply that accessing the sg device node should be sufficient. Why do I have to say "dev=x,y,z" instead of "dev=/dev/sgx"?
SCSI too? I always have to fiddle with strange SCSI IDs directly in userspace. I never understood what part of the CD burner's functionality is accessed through the device node, and what part is accessed using those strange dev= parameters to cdrecord. I wonder why this can't be dealt with in a more unixish way, i.e. using a device node and bunch of ioctls alone.
That said, I also don't know what this "HAL" thing is supposed to be useful for.
It was probably accelerated to escape velocity by an impacting asteroid millions of years ago.
How is this done? The result links don't point to redirections...
If you look at the statistics more closely, you'll probably notice that improved hygienic conditions have increased the average life expectancy more than all medical advantages ever made combined. Life expectancy 200yrs ago was 45 or so, today it's 80, but the standard deviation was much higher then than it is now (that is, there were *many* more 90-year-olds 200yrs ago than there are 160-year-olds today).
This means that "god" probably never intended us to die at 40, it's just that these days more people reach their "pre-defined" life expectancy instead of being wiped out by some minor unpleasantness long before their time has run out.
As I was saying, it amounts to just the opposite of capitalism. I'm not against people wanting to earn money, I'm against the crazy software patent laws enabling them to do it in anti-competitive, *socialist* ways.
That's the same crap as can be found e.g. here. I.e. "use software patents to regulate competition and enforce standards". You might as well opt for introducing socialism, with the patent office becoming the ruling communist party, and M$, Sun, IBM, and, of course, Eolas, becoming state-approved monopolies.
If the guy honestly believes that he does the software industry as a whole any good by forcing it to adhere to a single "technology" that tries to put EJBs, .NET, DCOM, SOAP, agents, browser plugins and whatnot under one hood, he's a complete lunatic.
But of course, he doesn't mean anything he says. He wants to squeeze as much money as possible out of the patent system without looking too much like a bad boy, and that's about it.
No.
It would be surprising if someone at MS has not thought of this. And just wait, MS may now be able to buy Macromedia at a lower price.
What's more, MS could more easily "persuade" people to switch to the ASP.NET client-side components (which are apparently not covered by the patent) in order to retain the "convenient user experience" they're accustomed to...
It may well be that they deem it cleverer to "lose" this case, thereby eliminating, among others, *Flash*, *Quicktime, the *Acrobat Reader Plugin*, and *Java Applets* from any and all browsers, and then force ASP.NET (including components running conveniently on the client, which works in IE only) down everyone's throat.
Please stop posting irrelevant links and tell us how M$ could possibly make those APIs publicly available and still retain all those "document expiration" features.
Or shut up.
They can't, because if they did, anybody could write software that reads those files and converts them to whatever format it wishes, thereby circumventing those nifty "document self-destroys tomorrow at 09:30 PM" features.
Looks like M$ is looking for new arguments to make developers pay licenses for their APIs.
Um, no it is not. The point that unauthorized users shouldn't be able to read the documents. Competing products should be able to read them, provided they know the required keys and can access the DRM server. This requires that MS documents the encryption format. Just as GnuPG etc do.
Judging from the screenshots, those just don't get rendered at all. Generally, the mapping algorithm to character cells seems to be quite smart though...
I think I'm breathing again...
...it would be sad if they stopped there. I propose the natural next step for them should be to kill their server product line :o).
Unless medical advances enable people to comfortably read font sizes of 1 mm (nobody wants huge displays on mobile phones) -- yes, I think they will.
And "conventional" displays will also be improved...
I agree. The major problem with Galeon is that it is a GNOME program instead of a simple GTK one. I really don't know why they chose to do this...