IIRC, I did try out an Emacs that I had compiled on 32-bit FC3, as also Sun's 32-bit JDK 1.4.
Both seemed to work fine
without needing to do anything special on a test install of 64-bit FC4.
Some clown in Sacramento had to deliberately remove this functionality [to save filled-in forms].
Actually, I suspect Adobe. Saving filled-in forms was not possible in Acrobat Reader 5 - only the full version of Acrobat. Acrobat 7 does give you
the "right" to save filled-in documents. I'm betting "rights management" is a new and or extra-cost feature of the program used to create the PDF files. The Feds have gotten around to updating their PDF-producing software, but California hasn't.
The concept of being allowed to print but not save
a document is the kind of insanity typical of
DRM-obsessed companies, of which it appears
Adobe is one. Hopefully there will be a
Free Software fix for this idiocy.
Microsoft can not prevent you from writing software that creates.doc files.
They can if the format is patented or depends on
patented algorithms (assuming the patents stand up in court).
Reverse engineering works as a defense in a copyright lawsuit, but won't protect you
from a patent lawsuit.
Edit your xorg.conf file and comment out all monitor specific settings such as HorizSync and VertRefresh.
Nope. This is a Presario R3000 laptop running Fedora Core 3, a fairly up-to-date distribution.
I've tried both NVidia drivers and the Free "nv" driver. Note the laptop has an unusual resoluton
(1680x1050), which may be a factor, but even
adding the Modeline (which normally works) doesn't help. The NVidia device may also be a factor;
it's possible it will "just work" with better-supported device and monitor resolutions.
However, at least on Fedora 3, note there are two
separate tools:
The "display settings" "system settings" tool can detect new types of displays, but it requires root, and restarting the
server to take effect. It rewrites the xorg.conf.
The "screen resolution preferences" dynamically
switches between "known" resolutions using the XRandR extension, and does not require root.
However, it does not appear to be able to
detect new displays with new resolutions.
the xserver automatically calculates allowed resolutions from the modelines it detects from the monitor
Yes, on start-up. I don't see any
indication that it does this when a new monitor
is detected.
but as of Gnome 2.6(?) go to System Tools|New Login or System Tools|New Login in a Nested Window
They're not in the Fedora Core 3 menu, which (according to
the Release Notes) has Gnome 2.8.
Actually, I don't care whether the X server has to be restarted. What I don't want to do is have to restart my applications (i.e. my session).
A virtualization layer
could solve the problem: my applications talk to
a FreeNX server. In that case the X server on my
display is just a client of the FreeNX server,
and its fine to restart the client, as long as
I don't have to restart my session.
I haven't had to specify a list of video modes in my xorg.conf or XFree86.conf in years. DDC takes care of automatically providing a list of supported modes. What ancient graphics card or monitor are you using, anyway?
You're missing the point. I'm talking about hot-plugging in a new monitor after configuring X. For example plugging
in an external monitor to a laptop, where the external monitor supports different modes than the
laptop monitor. And doing so without having
to restart the X server. Or plugging in a fancy
new monitor into your desktop box, again
without restarting X.
What I'm really waiting for is easier and dynamic configuration, including true hot-plugging of displays. I want to be able to plug in a new monitor and have X recognizes it. You can dynamically resize the screen to a limited extent,
but the available video sizes are still limited to what's in the xorg.conf.
Also, why don't we have fast user switching? I want to have multiple desktops belonging to multiple users, and switch between them quickly.
Fast user switching can be viewed as a special case of screen virtualization: Your applications
are always talking to virtual server, either VNC or (better) NX. A physical display can then
switch between different virual servers, multiple
displays can share the same server, you can move
display, or you can switch users.
This kind of stuff is much more important than
eye candy, and you'll have more of a chance to
make a name for yourself.
Living in California, if I so much as breathe a single word about God, I am immeadiately told to cease and desist.
Rubbish. I have been to Gay Pride rallies where fundamentalist idiots were allowed to use bullhorns to say we're going to hell, and when I protested the policeman said it was their First Amendment right. With a bullhorn? At our parade? Do you think I would be
able to propagandize with a bullhorn against the
fundamentalists at
one of their rallies - even in California?
On the other hand, we're supposed to be quiet on
the near-to-last section of a very short parade route (San José) because it's passing by a church.
You may be treated like that in the south, but we're treated like that everywhere else.
Utter nonsense. We're living in a country
where all national politicians and almost all
local politicians claim to be religious, where
almost none dare admit to scepticism, where
creationism is taken seriously by central
government and science publishers,
and where a majority (IIRC) of the voters in
serveys say they won't vote for someone who
doesn't claim to at least some kind of religious faith.
The persecution complex and gall of these people is incredible.
Re:distcc and ccache is better than compile server
on
GCC 4.0 Preview
·
· Score: 1
Distcc doesn't save you time in preprocessing, optimizing, or code generation.
Ooops. On re-reading, I overstated this: distcc
can speed up optimizing and code generation, since
they get distributed. It can't speed up lexing or
preprocessing, since that is centralized, and it
loses the benefit of having the pre-processor and
lexer interleaved, as Gcc currently does.
Re:distcc and ccache is better than compile server
on
GCC 4.0 Preview
·
· Score: 2, Insightful
Should one respond to half-truths and flame-bait from Anonymous Cowards?
Saying that distcc is "less error prone" is a meaningless statement since you're comparing distcc against an unfinished project.
The compile server can work "even when preprocessor tricks are used" - give us credit for having thought about the issues, and having come
up with solutions, albeit partially implemented
and not necessarily optimal.
Your compile server makes a lot of assumptions that many popular projects break.
So what?
As long as many projects can benefit
from it. If some projects benefit, that would
encourage other projects to clean up their
header files, which would be a good thing in itself. (A side benefit of the compile
server is that it encourages clean design.)
I agree discc is far simpler, and it will be
challenging to engineer a compile server that
can detect and recover from header files that
aren't "clean", without
the checks taking so much time we lose most
of the benefit. It's essentially research,
and there is no guarantee that it would justify the
investment needed. But it does have good
potential.
Note there are some limitations for distcc.
First, of course it assumes you have multiple
idle machines you can spread your compiles to.
That may not be the case in a home environment
or when travelling.
Second, shipping pre-processed source code all
over the place is quite expensive. Distcc doesn't
save you time in preprocessing, optimizing,
or code generation. All it helps with is parsing
and semantic analysis, so the best it can
give you is a modest constant-time improvement.
By this I mean that if you have M files that
include N header files each, the compile-time
with distcc is O(M*N), but with the compile
server it could potentially be O(M+N).
Re:Major Features Dropped From GCC 4.0
on
GCC 4.0 Preview
·
· Score: 2, Informative
The compiler server branch is as far as I know
not being worked on.
At least I han't done any work on it since I left Apple. I've done some vaguely related follow-on
and cleanup-work, such as adding support for column
numbers for declarations, expressions, and rtl.
However, no work on the compile server branch itself. I haven't noticed anyone else working on it.
It's a shame, since I think the compile server has major potential - and not only in terms of
improving compile speed.
However, there is still a significant amount of work without a guaranteed
payoff, and I guess Apple decided to spend its
resources elsewhere. Also, various
issues make it difficult for me to work much
on the project.
so adding a (tm) would satisfy the law 100% then.
"I am not a lawyer", but no, not necessarily.
Referring to the competition isn't the only issue. More important, I believe, is to not mislead people: implying that you're associated with the trademark owner or product; or that you're endorsed by the trademark owner; or that you are an agent of the trademark owner; or
that your product is the trademarked product; or that the name is generic rather than trademarked. You can't say: "Use our copier to quickly Xerox your documents", and adding a (tm) doesn't change that. It's not just wilfully implying - any statement that could plausibly mislead people, even if you don't intend to, is likely to get a "cease and desist".
how does their linking violate a trademark?
I don't know - the complaint isn't too specific, and the web site has been modified in response to the complaint. But here's an illustration:
Centos is compatible with <a href="redhat.com">Red Hat Enterprise Linux</a>.
I don't know if this would be an illegal trademark
violation, but it's at least a gray area, and
something I would expect Red Hat's lawyers to
complain about.
The cited court base was based on copyright law: Hyperlinking does not itself involve a violation of the Copyright Act," Hupp said in his ruling.. Red Hat's lawyers are complaining about trademark misuse. That is very different. Creating a link is legal, but it would have to be done in a way that doesn't violate Red Hat's trademark.
Most people use an OS, program, language, whatever because of the *benefits*, not because of some ideology.
That's not an argument: Most people do foolish things. More specifically, things that are easy
in the short-term, but may hurt in the long-term.
(Most programmers don't use version-control systems, which is really scary!)
One example: putting all you documents in a proprietary undocumented format so your documents
are at the mercy of one company.
Another example is writing your programs in a
proprietary language, and/or one that has no specification beyond the implementation.
Java isn't quite in either of those positions,
but as usual Stallman is more right than those
who would dismiss him without even understanding
his points.
For those who don't know, GCC doesn't have a single person that approves patches, like Linus, but instead any nontrivial patch needs to be reviewed and OK'd by two mantainers (one if the writer is a mantainer)...
Not quite: Maintainers can check in their own
patches (within the code they maintain) without
waiting for approval. Other patches only need to be approved by a single maintainer.
To handle transformations (as a separate issue from styling) the new XQuery language has some advantages over XSLT.
The syntax is a lot more readable and more concise, and it's actually a reasonable programming language. It's a superset of XPath, which may people (including XSLT users) are familiar with. On the other hand, it doesn't have XSLT's "template processing" model, which simplifies writing transformations, and it's not
a finished standard yet (though it's close).
My article
discusses and illustrates using XQuery to transform XML for presentations. It's
about generating web pages, while the parent is about generating PDF, but it does suggest it might be worth trying XQuery for generating XSL-FO (or even XHTML+CSS).
None of the listed meanings mean "thinking for oneself." The first definition is closest, but the cited dictionary is wrong is citing it as the primary meaning. For one thing it is quite possible to be dogmatically liberal - it even has a name: being Poltically Correct.
As for liberal, look up the definition. It simply means "thinking for yourself."
I consider myself a liberal, but this is nonsense.
The root word of liberal is "liberty" or "freedom"
- it has nothing to do with "thinking for oneself".
I wish moderators would stop equating
"I agree with this" with "Informative", because
this clearly isn't.
I wish they had standardized on YYYY/MM/DD instead, since that would have made it easier to add date ranges. That's why I sometimes write things like 2004/11/19-21, even though it isn't standard. The hyphen character just seems the wrong choice.
To start with, imagine having to escape scripts like this... and styles.
The fear appears to be overblown. You might want to take a look a Wikipedia.
It serves up XHTML 1.0 Transitional, even to
IE 5.2 (Mac version) - I just tested. Seems
to work fine.
Of course the secret is to not include large
script or style code inline in the XHTML, but to
store them in separate files.
Also note that the context of this discussion is Wiki content,
which don't use scripts and styles. Now a page
served up for viewing might use scripts and styles,
but that is all boilerplate: i.e. skin rather than content. As such it should not be stored in the
"database", but can be added by the server, which
could also if needed convert XHTML to HTML.
IE and other old browsers handle XHTML just fine,
assuming you follow the
Compatibility Guidelines.
Note that I'm primarily urging XHTML as the
file format used on the server. Secondarily,
I'm urging that people use XHTML/HTML for
editing. Note I tried to carefully distinguish
HTML and XHTML in my post: The server should
send HTML-compatible XHTML to the client's
editor, and if it gets HTML it should
"clean it up" to make XHTML.
In practice a server could use client detection
to use Mozile when suitable,
and something like rte otherwise.
In a world with lots of nice user-friendly WYSIWYG
HTML editors, the idea of special "easy-to-use" Wiki
markup is an anachronism. A Wiki page should be XHTML, and editing it should mean editing the XHTML.
For most users, that editing would be done by a
GUI HTML editor.
The file format should be XHTML. Using XHTML rather than HTML allows using XML tools and
easier "data mining". Using HTML/XHTML as the
native file format means that you can view a
snapshot of the actual source in any
browser without a server, and edit it with any
HTML editor.
What is missing is nice integration of the tools:
When I click Edit that should bring up my
favorite HTML editor - which might be Emacs!
When I save the HTML, the resulting HTML should
be copied back to the server,
which should validate it,
convert the HTML to XHTML if needed, and then
check the result into a version control system.
When a server presents a page, it could do a
little trivial munging, perhaps embedding the
<body> inside a frame or
add some CSS hooks, plus adjusting the <head>
and top-level <html> to match
site conventions.
I'd expect short lived applications where JVM startup time is significant, or ones with very few loops or other repeated code to [run faster with
precompilation], while long lived processes that basically repeat the same sequence of instructions (eg video codecs) would [run faster with a JIT].
That that seems likely in general. However, applications that are dominated by relatively small
instruction sequences are likely to show higher
variability in generated code for different
compilers. Just like it's hard to predict
which options of the same compiler
will work best on a given application, one
compiler may do better with one code sequence
while another does better on a different code
sequence. So then it's a question of which
code sequence dominates the application.
The big advantage of a JIT is that it can generate code
optimistically in some cases, such as assuming
that a method is not overridden. If later a
class is loaded such that the method is
overridden, it can just recompile the code.
This advantage is much reduced if one does
whole-program optimization, where the compiler
has access to all the classes that may be loaded.
The big advantage of precompilation is that one
can afford to do more extensive time-consuming
analysis and optimization.
Slashdot Mirror
IIRC, I did try out an Emacs that I had compiled on 32-bit FC3, as also Sun's 32-bit JDK 1.4. Both seemed to work fine without needing to do anything special on a test install of 64-bit FC4.
Actually, I suspect Adobe. Saving filled-in forms was not possible in Acrobat Reader 5 - only the full version of Acrobat. Acrobat 7 does give you the "right" to save filled-in documents. I'm betting "rights management" is a new and or extra-cost feature of the program used to create the PDF files. The Feds have gotten around to updating their PDF-producing software, but California hasn't.
The concept of being allowed to print but not save a document is the kind of insanity typical of DRM-obsessed companies, of which it appears Adobe is one. Hopefully there will be a Free Software fix for this idiocy.
They can if the format is patented or depends on patented algorithms (assuming the patents stand up in court). Reverse engineering works as a defense in a copyright lawsuit, but won't protect you from a patent lawsuit.
Nope. This is a Presario R3000 laptop running Fedora Core 3, a fairly up-to-date distribution. I've tried both NVidia drivers and the Free "nv" driver. Note the laptop has an unusual resoluton (1680x1050), which may be a factor, but even adding the Modeline (which normally works) doesn't help. The NVidia device may also be a factor; it's possible it will "just work" with better-supported device and monitor resolutions.
However, at least on Fedora 3, note there are two separate tools:
The "display settings" "system settings" tool can detect new types of displays, but it requires root, and restarting the server to take effect. It rewrites the xorg.conf.
The "screen resolution preferences" dynamically switches between "known" resolutions using the XRandR extension, and does not require root. However, it does not appear to be able to detect new displays with new resolutions.
the xserver automatically calculates allowed resolutions from the modelines it detects from the monitor
Yes, on start-up. I don't see any indication that it does this when a new monitor is detected.
but as of Gnome 2.6(?) go to System Tools|New Login or System Tools|New Login in a Nested Window
They're not in the Fedora Core 3 menu, which (according to the Release Notes) has Gnome 2.8.
Actually, I don't care whether the X server has to be restarted. What I don't want to do is have to restart my applications (i.e. my session). A virtualization layer could solve the problem: my applications talk to a FreeNX server. In that case the X server on my display is just a client of the FreeNX server, and its fine to restart the client, as long as I don't have to restart my session.
You're missing the point. I'm talking about hot-plugging in a new monitor after configuring X. For example plugging in an external monitor to a laptop, where the external monitor supports different modes than the laptop monitor. And doing so without having to restart the X server. Or plugging in a fancy new monitor into your desktop box, again without restarting X.
What I'm really waiting for is easier and dynamic configuration, including true hot-plugging of displays. I want to be able to plug in a new monitor and have X recognizes it. You can dynamically resize the screen to a limited extent, but the available video sizes are still limited to what's in the xorg.conf.
Also, why don't we have fast user switching? I want to have multiple desktops belonging to multiple users, and switch between them quickly.
Fast user switching can be viewed as a special case of screen virtualization: Your applications are always talking to virtual server, either VNC or (better) NX. A physical display can then switch between different virual servers, multiple displays can share the same server, you can move display, or you can switch users.
This kind of stuff is much more important than eye candy, and you'll have more of a chance to make a name for yourself.
Rubbish. I have been to Gay Pride rallies where fundamentalist idiots were allowed to use bullhorns to say we're going to hell, and when I protested the policeman said it was their First Amendment right. With a bullhorn? At our parade? Do you think I would be able to propagandize with a bullhorn against the fundamentalists at one of their rallies - even in California?
On the other hand, we're supposed to be quiet on the near-to-last section of a very short parade route (San José) because it's passing by a church.
You may be treated like that in the south, but we're treated like that everywhere else.
Utter nonsense. We're living in a country where all national politicians and almost all local politicians claim to be religious, where almost none dare admit to scepticism, where creationism is taken seriously by central government and science publishers, and where a majority (IIRC) of the voters in serveys say they won't vote for someone who doesn't claim to at least some kind of religious faith.
The persecution complex and gall of these people is incredible.
Ooops. On re-reading, I overstated this: distcc can speed up optimizing and code generation, since they get distributed. It can't speed up lexing or preprocessing, since that is centralized, and it loses the benefit of having the pre-processor and lexer interleaved, as Gcc currently does.
Saying that distcc is "less error prone" is a meaningless statement since you're comparing distcc against an unfinished project. The compile server can work "even when preprocessor tricks are used" - give us credit for having thought about the issues, and having come up with solutions, albeit partially implemented and not necessarily optimal.
Your compile server makes a lot of assumptions that many popular projects break.
So what? As long as many projects can benefit from it. If some projects benefit, that would encourage other projects to clean up their header files, which would be a good thing in itself. (A side benefit of the compile server is that it encourages clean design.)
I agree discc is far simpler, and it will be challenging to engineer a compile server that can detect and recover from header files that aren't "clean", without the checks taking so much time we lose most of the benefit. It's essentially research, and there is no guarantee that it would justify the investment needed. But it does have good potential.
Note there are some limitations for distcc. First, of course it assumes you have multiple idle machines you can spread your compiles to. That may not be the case in a home environment or when travelling. Second, shipping pre-processed source code all over the place is quite expensive. Distcc doesn't save you time in preprocessing, optimizing, or code generation. All it helps with is parsing and semantic analysis, so the best it can give you is a modest constant-time improvement. By this I mean that if you have M files that include N header files each, the compile-time with distcc is O(M*N), but with the compile server it could potentially be O(M+N).
It's a shame, since I think the compile server has major potential - and not only in terms of improving compile speed. However, there is still a significant amount of work without a guaranteed payoff, and I guess Apple decided to spend its resources elsewhere. Also, various issues make it difficult for me to work much on the project.
so adding a (tm) would satisfy the law 100% then.
"I am not a lawyer", but no, not necessarily. Referring to the competition isn't the only issue. More important, I believe, is to not mislead people: implying that you're associated with the trademark owner or product; or that you're endorsed by the trademark owner; or that you are an agent of the trademark owner; or that your product is the trademarked product; or that the name is generic rather than trademarked. You can't say: "Use our copier to quickly Xerox your documents", and adding a (tm) doesn't change that. It's not just wilfully implying - any statement that could plausibly mislead people, even if you don't intend to, is likely to get a "cease and desist".
I don't know - the complaint isn't too specific, and the web site has been modified in response to the complaint. But here's an illustration:
I don't know if this would be an illegal trademark violation, but it's at least a gray area, and something I would expect Red Hat's lawyers to complain about.
The cited court base was based on copyright law: Hyperlinking does not itself involve a violation of the Copyright Act," Hupp said in his ruling.. Red Hat's lawyers are complaining about trademark misuse. That is very different. Creating a link is legal, but it would have to be done in a way that doesn't violate Red Hat's trademark.
That's not an argument: Most people do foolish things. More specifically, things that are easy in the short-term, but may hurt in the long-term. (Most programmers don't use version-control systems, which is really scary!) One example: putting all you documents in a proprietary undocumented format so your documents are at the mercy of one company. Another example is writing your programs in a proprietary language, and/or one that has no specification beyond the implementation. Java isn't quite in either of those positions, but as usual Stallman is more right than those who would dismiss him without even understanding his points.
Not quite: Maintainers can check in their own patches (within the code they maintain) without waiting for approval. Other patches only need to be approved by a single maintainer.
To handle transformations (as a separate issue from styling) the new XQuery language has some advantages over XSLT. The syntax is a lot more readable and more concise, and it's actually a reasonable programming language. It's a superset of XPath, which may people (including XSLT users) are familiar with. On the other hand, it doesn't have XSLT's "template processing" model, which simplifies writing transformations, and it's not a finished standard yet (though it's close). My article discusses and illustrates using XQuery to transform XML for presentations. It's about generating web pages, while the parent is about generating PDF, but it does suggest it might be worth trying XQuery for generating XSL-FO (or even XHTML+CSS).
None of the listed meanings mean "thinking for oneself." The first definition is closest, but the
cited dictionary is wrong is citing it as the
primary meaning. For one thing it is quite possible
to be dogmatically liberal - it even has a
name: being Poltically Correct.
I consider myself a liberal, but this is nonsense. The root word of liberal is "liberty" or "freedom" - it has nothing to do with "thinking for oneself".
I wish moderators would stop equating "I agree with this" with "Informative", because this clearly isn't.
If you require 4-digit years then there is no
ambiguity between DD/MM/YYYY and YYYY/MM/DD.
I wish they had standardized on YYYY/MM/DD instead,
since that would have made it easier to add date ranges. That's why I sometimes write things like
2004/11/19-21, even though it isn't standard.
The hyphen character just seems the wrong choice.
The fear appears to be overblown. You might want to take a look a Wikipedia. It serves up XHTML 1.0 Transitional, even to IE 5.2 (Mac version) - I just tested. Seems to work fine.
Of course the secret is to not include large script or style code inline in the XHTML, but to store them in separate files.
Also note that the context of this discussion is Wiki content, which don't use scripts and styles. Now a page served up for viewing might use scripts and styles, but that is all boilerplate: i.e. skin rather than content. As such it should not be stored in the "database", but can be added by the server, which could also if needed convert XHTML to HTML.
Note that I'm primarily urging XHTML as the file format used on the server. Secondarily, I'm urging that people use XHTML/HTML for editing. Note I tried to carefully distinguish HTML and XHTML in my post: The server should send HTML-compatible XHTML to the client's editor, and if it gets HTML it should "clean it up" to make XHTML.
In practice a server could use client detection to use Mozile when suitable, and something like rte otherwise.
The file format should be XHTML. Using XHTML rather than HTML allows using XML tools and easier "data mining". Using HTML/XHTML as the native file format means that you can view a snapshot of the actual source in any browser without a server, and edit it with any HTML editor.
What is missing is nice integration of the tools: When I click Edit that should bring up my favorite HTML editor - which might be Emacs! When I save the HTML, the resulting HTML should be copied back to the server, which should validate it, convert the HTML to XHTML if needed, and then check the result into a version control system.
When a server presents a page, it could do a little trivial munging, perhaps embedding the <body> inside a frame or add some CSS hooks, plus adjusting the <head> and top-level <html> to match site conventions.
That that seems likely in general. However, applications that are dominated by relatively small instruction sequences are likely to show higher variability in generated code for different compilers. Just like it's hard to predict which options of the same compiler will work best on a given application, one compiler may do better with one code sequence while another does better on a different code sequence. So then it's a question of which code sequence dominates the application.
The big advantage of a JIT is that it can generate code optimistically in some cases, such as assuming that a method is not overridden. If later a class is loaded such that the method is overridden, it can just recompile the code. This advantage is much reduced if one does whole-program optimization, where the compiler has access to all the classes that may be loaded.
The big advantage of precompilation is that one can afford to do more extensive time-consuming analysis and optimization.