No, all he wants to say is that ExxonMobil has a comprehensive economic plan that will create millions of good American jobs and ensure the nation's energy security:)
My advice wasn't for the submitter because the OP in this thread was also not addressing the submitter (the submitter obviously has no say whether or not his company will actually enforce the patent once the got it).
There is a one year "grace period" in which you can still patent it. But that was not my point. It appears we read the comment of the OP differently:
* I interpreted his statement in the general sense: if you (as a company or person) are against software patents, the best thing is to get the patents yourself since then nobody else can still get them. I simply replied that if that is your goal, it's better to simply publish things.
* You interpreted it as specific to the situation of the submitter. But I don't think that's a real possibility, since he obviously did the work while hired by his company, hence the work belongs to that company and he cannot (legally) go out and patent (nor publish, for that matter) the work in his own name. Personal publishing in that case would possibly not even count as a publication, because it presumably wasn't authorised by the company (you can't put trade secrets back into the box, but you can do that with pretty much else).
The best thing is to publish it. If you patent it even without intending to enforce it, the patent can still be acquired later by someone who will. In fact, that's exactly what happened with the lzw/gif patent.
There's nothing strange about Russia flexing its muscle. The whole reason that Putin became so popular is because he made sure that Russia was again taken seriously after Yeltsin's era. He may be oppressive to a certain extent and the riches may go mainly to his friends, but at least Russia is respected again.
And sure, Putin's Russia (and possible Medvedev's as well) is quite dangerous in various ways. But so are various terrorist organisations. However, they are nothing compared to the political leaders of the so called "free and democratic western world" who use those spectres to completely undermine the foundations of our society and let themselves be used by idiots dreaming about fantasy worlds they can only save by having ever increasing surveillance powers.
They probably honestly think they are doing this for the best of all, but somehow they lose sight of the fact that they are completely destroying whatever it is that they are supposed to be protecting in the process. But when things happen gradually, it's often very hard to notice stuff like that, especially when you're in the middle of it.
sources close to the intelligence community say that Russia is the prime target
... because they figured that people are tired of hearing the terrorists story, and therefore came up with a different enemy to justify their hunger for control.
Just what I would have wanted my unelected EMPs to do on my behalf.
The EMP's, who are actually directly elected, have nothing to do with this agreement (and if you'd read the article, you'd see they are more critical of it than anyone else).
It's being negotiated by the Commission with a mandate of the EU Council of Ministers (who will later still have to, and probably will, approve it). The EU Council of Ministers consists of the ministers from all national governments (different ministers depending on the subject being discussed). You know, those ministers who always approve unpopular measures when they're in the Council and then later at home blame the EU for having to implement those same measures in national law.
If by "strike" you mean "being found guilty of some crime by a jury of your peers" then sure. But I don't think that's what the media companies have in mind..
Indeed. One of the big problems is that you can only appeal the final warning. I.e., if the first warnings were completely baseless (e.g., because you download a file with a name similar to some RIAA/MPAA blockbusters but with completely different content) and the final one turns out to be factual, then you're out too.
Write a simple c or c++ hello_word program. Then try to compile and link it with Xcode using -static. It won't work b/c Apple has fucked-up ld. It has nothing to do with ld. The reason it doesn't work is that there is no static version of libc (aka libSystem) on Mac OS X. And the reason for that is that on Mac OS X, libc is the lowest level publicly supported system interface.
There are of course system calls (both BSD-style and Mach-style ones), but they are undocumented and can change from one Mac OS X version to another (even between minor system updates). The reason is that Apple wants to have and keep full freedom in changing the systemuser space interface at any time it wants whenever that's convenient for whatever reason (performance, security, getting rid of legacy cruft,...).
So if you'd statically link a program, it would be linked to a particular libc version which in turn would use the system calls as they work on the particular version of Mac OS X this libc version was compiled for. The end result would be that your program would only be guaranteed to function correctly on that particular OS revision.
libc's interface on the other hand is kept backwards compatible between OS revisions, so as long as you dynamically link against it, your program will work fine on pretty much any OS version out there (except if you use APIs which didn't exist yet in older versions).
This is more or less the opposite case as on e.g. Linux, where glibc breaks binary compatibility every other full moon (so you need to distribute different binaries for different glibc versions if you want to link dynamically to it), but the kernel's system call interface is pretty much guaranteed to remain backwards compatible for a very long time (so statically linked binaries are generally much more portable across distributions â" the downside is that you then should link everything statically because installed dynamic libraries may rely on features provided by a newer glibc than the one you statically linked, and in case of e.g. a KDE or GNOME app you'd end up with immense binaries).
No, there are three possible versions of most updates: combo updates which can be applied to any previous version (with the same major version number), regular updates which update Mac OS X a.b.m to a.b.n, and delta updates which do the same as a regular update but which are smaller (due to the use of binary patches rather than including all replaced files in full).
The ability for software update to use delta updates was introduced in Mac OS X 10.3.4, as the support document I linked to implies (it's not like before 10.3.4 you only had combo updates).
Which, seems to me, is one of the reasons why rollback is non trivial. No, because updates with entire files are also available. Rollback is non-trivial because Apple is still busy with reinventing the functionality which already exists in most package management systems. Its current installer doesn't even fully support a plain uninstall operation (you can force it via the command line, but it still has several limitations), let alone rolling back an OS upgrade (although you could perform rollback already using Time Machine, I guess)
Don't get angry, get even
on
I Will Derive
·
· Score: 5, Funny
Thanks to you and the GP for the inspiration:) And this is just to get rid of the "too few characters per line" complaint from the filter.
First I thought "Oh fuck, this is travesty". The Slashlords fin'ly lost their touch, this really cannot be. But the idle section stayed, and while I cried out "This is wrong", the trolls grew strong. And even Taco plays along! Yes, they are back from all the chans. They took the training for the flaming and are here to grab their chance. Oh, do you think you have seen bad, well then you're in for a surprise. Cause on the one hand there is fluff but now get ready for demise!
Go Taco go, give junk the floor. Ignore your readers. Nerds don't matter anymore. This idle style is hot, we are taking over Fark. Yet still I wonder... Did Slashdot really jump the shark? Don't link YouTube, just post a dupe! About cold fusion with hot grits greased by Piquepaille's lube. Even Katz stories are fine Even goatse seems divine when idle's stage is the frontpage.
While this may sound like I'm new, my ID confides that while I could not pay for lower ones I've seen the tides. It seems the terrorists have won. Breakouts of common sense are gone. I used to mod. Now I'm just one more old sod. And I say now, get off my lawn! I hope that in Korea's shelters I can still respawn. And you can stick your idle site, its sorry style like soylent green. I'd rather pony up for pink and I bet so does your Kathleen...
Go Taco go, give junk the floor....
(alternate part for "Yes, they are back...":
Slashdot cries out, The movie blares. Oh yes, on weekends they'll submit it till the firehose declares that the frontpage is their scene, the idle section is their heir, and if you don't vote for those films we've still got Jamie over there... )
As the user comment on imdb says: "This animation TV series is simply the best way for children to learn how the human body works. Yes, this is biology but they will never tell it is." That's exactly how I remember it from when I saw it (and at the same time, a lot of the information stuck and came back later on when I learned about those topics in school).
There's a related one about space ( http://www.imdb.com/title/tt0282303/ ), but as far as I remember that was less edutainment and more pure entertainment.
Send a DMCA take down notice to the hosting provider since the contents of the website infringe on your copyright?:) You shouldn't even need a lawyer for that, as there are plenty of RIAA and MPAA examples floating around...
'm not against Pascal as a language, I just question why we need yet another toolchain. Why not write a good pascal frontend for GCC and then take advantage of all the platforms they support + optimizers, etc. The optimizers in GCC are hardly language specific, most of them work on very abstract machine representations after the language has been compiled to an independent machine type.
The main reason is that GCC is written in C, while Free Pascal is written in Pascal (it's self-compiling). All FPC developers are much more proficient and productive in developing in Pascal than developing in C (although most of them do know C as well). FPC also has a reasonably easy to understand OOP design for its code generator and parse tree and is still small enough so one single person can have a pretty good overview of the entire thing. The same cannot be said of GCC.
As far as generic optimizers etc. are concerned, I've been thinking lately of adding a code generator backend which spits out LLVM code.
Suppose I'm a developer in a company. We work with, say, crypto software, on a variety of embedded platforms [not all of which run Linux]. Please tell me why I should consider Pascal.
The primary criterium is that there is a compiler available which supports your target platform. Because you're comfortable with the language and are more productive using it that when using C or another language. If you aren't, nor see anything that entices you to learn it, by all means stay away from it as far as you can because using a language you don't like at all will only reduce your productivity (and your enjoyment of programming).
Or, suppose I've been dropped into a company with millions of dollars of existing software toolkits [all written in C]. Please tell me why we should port it all to Pascal?
I don't think you should, it would be hell to port that much software from one language to another. You can easily use all of those from within (new) Pascal programs though, should you want to.
Pascal is cool and all, but until I can be reasonably assured to find it everywhere, in a project [like GCC] that I can be assured will be here in 5 years, I can't really promote it in any of my projects.
GCC has been around for 2 decades or so. It has scores of contributors from all walks of life and industry. Can you say the same for Free Pascal?
As someone else mentioned, FPC has been around since 1993. Not quite as old as GCC, but it's still respectable imp. We don't have contributors from IBM, Apple, ARM etc. Most professional contributors to FPC work in small companies that used Delphi until now, and they mostly contribute patches to the component libraries rather than to the compiler.
Strings were also what made me hate Pascal. Delphi included support for two kinds of string, C strings and Pascal strings. C strings were NULL-terminated, Pascal strings had one byte at the start indicating their length. In principle, this isn't a problem, but a lot of API functions took C strings, but the documentation said they took Pascal strings. They would then iterate over the length of the string, and keep going well beyond the end because they never found a terminating NULL byte. The program would then crash.
I don't understand how this could happen. If you'd try to pass a shortstring (a UCSD Pascal string) to a routine declared as taking a pchar (= pointer to a char = C string), you'd get a type check error at compile time.
- compiled more than one compilation unit (sourcefile) per execution of the compiler.
- not having to interpret source to compile something dependant (IOW precompiled units)
gcc can also do both of these things (at least nowadays), although Makefiles seldom make use of the former ability (but e.g. Apple's Xcode does). Its precompiled headers should even be a lot faster than fpc's, since they are plain memory dumps in case of gcc. And at least for most system headers as used in a single application, the argument of "defines which change all the time mostly defeat their purpose" is unlikely to hold (at least not after the first compilation).
- integrating AS. This is a factor 5 easily
Also with external assembling, fpc is still much faster at compiling than gcc. It's also not a factor 5 on the total compilation speed, but only on the part spent on assembling.
I think the main reason for fpc's speed is simply that the compiler is much less complex (to the extent that a single person can still have a pretty good overview of pretty much the entire workings), while that cannot be said of gcc. And of course, fpc does a lot less passes over all the code.
Possibly. I think for similar programs though the extra checks shouldn't come into account. Pascal always checked array boundaries, and so long as you are only doing standard programming (no subtypes, no derived types etc.) it should be comparable.
At least Turbo Pascal and Free Pascal support range checking for subtypes. FPC also supports checking type casts from one object/class type to another. Most checks are only turned on for debug builds though, which is a big difference with Ada.
Does FreePascal precompile things?
It keeps precompiled versions of interfaces, yes. But even when building from scratch, FPC is a lot faster than gcc. In general, gcc is simply a slow compiler (I've recently heard it does over 200 passes over each compiled function, so actually it is lightning fast relative to the work it does, but in absolute numbers it's still pretty slow (even with all optimizations turned off).
While it would probably have been less effort for them to contribute a win64 port to binutils
Probably not. FPC already had an internal i386 assembler, based on the tables of nasm. Those were simply extended for x86_64, iirc even based on beta patches to nasm. And the main reason for an internal linker was not x86_64 support, but the fact that ld is very slow and memory hungry (in particular on Windows). Also, by skipping all intermediate steps in the process of internal assembler representation -> text representation -> gas -> object files -> ld parsing object files again -> final binary, you obviously get an inherent speedup.
Both this internal assembler and linker are written in Pascal like the rest of the compiler, and therefore are much less work for the FPC team to write/test/debug than GNU as/ld (as most FPC developers are much more used to developing in Pascal than in C, not to mention that they know FPC inside out while this is not the case for the binutils).
That said, I'm personally also not a fan of duplicating functionality like that and will probably never do it for the FPC targets which I support, but I just wanted to correct your (wrong) notion that the people who wrote the internal assembler/linker could just as easily have added that support to the binutils.
Slashdot Mirror
No, all he wants to say is that ExxonMobil has a comprehensive economic plan that will create millions of good American jobs and ensure the nation's energy security :)
My advice wasn't for the submitter because the OP in this thread was also not addressing the submitter (the submitter obviously has no say whether or not his company will actually enforce the patent once the got it).
See http://slashdot.org/comments.pl?sid=648211&cid=24633253
There is a one year "grace period" in which you can still patent it. But that was not my point. It appears we read the comment of the OP differently:
* I interpreted his statement in the general sense: if you (as a company or person) are against software patents, the best thing is to get the patents yourself since then nobody else can still get them. I simply replied that if that is your goal, it's better to simply publish things.
* You interpreted it as specific to the situation of the submitter. But I don't think that's a real possibility, since he obviously did the work while hired by his company, hence the work belongs to that company and he cannot (legally) go out and patent (nor publish, for that matter) the work in his own name. Personal publishing in that case would possibly not even count as a publication, because it presumably wasn't authorised by the company (you can't put trade secrets back into the box, but you can do that with pretty much else).
The best thing is to publish it. If you patent it even without intending to enforce it, the patent can still be acquired later by someone who will. In fact, that's exactly what happened with the lzw/gif patent.
There's nothing strange about Russia flexing its muscle. The whole reason that Putin became so popular is because he made sure that Russia was again taken seriously after Yeltsin's era. He may be oppressive to a certain extent and the riches may go mainly to his friends, but at least Russia is respected again.
And sure, Putin's Russia (and possible Medvedev's as well) is quite dangerous in various ways. But so are various terrorist organisations. However, they are nothing compared to the political leaders of the so called "free and democratic western world" who use those spectres to completely undermine the foundations of our society and let themselves be used by idiots dreaming about fantasy worlds they can only save by having ever increasing surveillance powers.
They probably honestly think they are doing this for the best of all, but somehow they lose sight of the fact that they are completely destroying whatever it is that they are supposed to be protecting in the process. But when things happen gradually, it's often very hard to notice stuff like that, especially when you're in the middle of it.
sources close to the intelligence community say that Russia is the prime target
... because they figured that people are tired of hearing the terrorists story, and therefore came up with a different enemy to justify their hunger for control.
I wish I has to face getting a lot of money from the lottery...
Just what I would have wanted my unelected EMPs to do on my behalf.
The EMP's, who are actually directly elected, have nothing to do with this agreement (and if you'd read the article, you'd see they are more critical of it than anyone else).
It's being negotiated by the Commission with a mandate of the EU Council of Ministers (who will later still have to, and probably will, approve it). The EU Council of Ministers consists of the ministers from all national governments (different ministers depending on the subject being discussed). You know, those ministers who always approve unpopular measures when they're in the Council and then later at home blame the EU for having to implement those same measures in national law.
Echelon's existence has been pretty thoroughly described and analysed by the European Parliament: http://www.europarl.europa.eu/sides/getDoc.do?type=REPORT&reference=A5-2001-0264&language=EN&mode=XML
(resolution on "the existence of Echelon": http://www.europarl.europa.eu/sides/getDoc.do?pubRef=-//EP//TEXT+TA+P5-TA-2001-0441+0+DOC+XML+V0//EN )
So I don't think you can still really call it a secret.
If by "strike" you mean "being found guilty of some crime by a jury of your peers" then sure. But I don't think that's what the media companies have in mind..
Indeed. One of the big problems is that you can only appeal the final warning. I.e., if the first warnings were completely baseless (e.g., because you download a file with a name similar to some RIAA/MPAA blockbusters but with completely different content) and the final one turns out to be factual, then you're out too.There are of course system calls (both BSD-style and Mach-style ones), but they are undocumented and can change from one Mac OS X version to another (even between minor system updates). The reason is that Apple wants to have and keep full freedom in changing the systemuser space interface at any time it wants whenever that's convenient for whatever reason (performance, security, getting rid of legacy cruft,
So if you'd statically link a program, it would be linked to a particular libc version which in turn would use the system calls as they work on the particular version of Mac OS X this libc version was compiled for. The end result would be that your program would only be guaranteed to function correctly on that particular OS revision.
libc's interface on the other hand is kept backwards compatible between OS revisions, so as long as you dynamically link against it, your program will work fine on pretty much any OS version out there (except if you use APIs which didn't exist yet in older versions).
This is more or less the opposite case as on e.g. Linux, where glibc breaks binary compatibility every other full moon (so you need to distribute different binaries for different glibc versions if you want to link dynamically to it), but the kernel's system call interface is pretty much guaranteed to remain backwards compatible for a very long time (so statically linked binaries are generally much more portable across distributions â" the downside is that you then should link everything statically because installed dynamic libraries may rely on features provided by a newer glibc than the one you statically linked, and in case of e.g. a KDE or GNOME app you'd end up with immense binaries).
Concrete example:
10.5.3 combo update: 536 MB
10.5.2 -> 10.5.3 update: 420 MB
10.5.2 -> 10.5.3 delta update: 198 MB
No, there are three possible versions of most updates: combo updates which can be applied to any previous version (with the same major version number), regular updates which update Mac OS X a.b.m to a.b.n, and delta updates which do the same as a regular update but which are smaller (due to the use of binary patches rather than including all replaced files in full).
The ability for software update to use delta updates was introduced in Mac OS X 10.3.4, as the support document I linked to implies (it's not like before 10.3.4 you only had combo updates).
Which, seems to me, is one of the reasons why rollback is non trivial. No, because updates with entire files are also available. Rollback is non-trivial because Apple is still busy with reinventing the functionality which already exists in most package management systems. Its current installer doesn't even fully support a plain uninstall operation (you can force it via the command line, but it still has several limitations), let alone rolling back an OS upgrade (although you could perform rollback already using Time Machine, I guess)
Apple does do delta updates.
Thanks to you and the GP for the inspiration :) And this is just to get rid of the "too few characters per line" complaint from the filter.
...
First I thought "Oh fuck,
this is travesty".
The Slashlords fin'ly lost their touch,
this really cannot be.
But the idle section stayed,
and while I cried out "This is wrong",
the trolls grew strong.
And even Taco plays along!
Yes, they are back
from all the chans.
They took the training for the flaming
and are here to grab their chance.
Oh, do you think you have seen bad,
well then you're in for a surprise.
Cause on the one hand there is fluff
but now get ready for demise!
Go Taco go, give junk the floor.
Ignore your readers.
Nerds don't matter anymore.
This idle style is hot, we are taking over Fark.
Yet still I wonder...
Did Slashdot really jump the shark?
Don't link YouTube,
just post a dupe!
About cold fusion with hot grits
greased by Piquepaille's lube.
Even Katz stories are fine
Even goatse seems divine
when idle's stage
is the frontpage.
While this may sound like I'm new,
my ID confides
that while I could not pay
for lower ones I've seen the tides.
It seems the terrorists have won.
Breakouts of common sense are gone.
I used to mod.
Now I'm just one more old sod.
And I say now,
get off my lawn!
I hope that in Korea's shelters
I can still respawn.
And you can stick your idle site,
its sorry style like soylent green.
I'd rather pony up for pink
and I bet so does your Kathleen...
Go Taco go, give junk the floor.
(alternate part for "Yes, they are back...":
Slashdot cries out,
The movie blares.
Oh yes, on weekends they'll submit
it till the firehose declares
that the frontpage is their scene,
the idle section is their heir,
and if you don't vote for those films
we've still got Jamie over there...
)
Not about the big bang etc, but as for biology this is a great series: http://www.imdb.com/title/tt0284735/
As the user comment on imdb says: "This animation TV series is simply the best way for children to learn how the human body works. Yes, this is biology but they will never tell it is." That's exactly how I remember it from when I saw it (and at the same time, a lot of the information stuck and came back later on when I learned about those topics in school).
There's a related one about space ( http://www.imdb.com/title/tt0282303/ ), but as far as I remember that was less edutainment and more pure entertainment.
And you can save a lot of electricity by replacing all your light bulbs with superconducting ones!
Send a DMCA take down notice to the hosting provider since the contents of the website infringe on your copyright? :) You shouldn't even need a lawyer for that, as there are plenty of RIAA and MPAA examples floating around...
The main reason is that GCC is written in C, while Free Pascal is written in Pascal (it's self-compiling). All FPC developers are much more proficient and productive in developing in Pascal than developing in C (although most of them do know C as well). FPC also has a reasonably easy to understand OOP design for its code generator and parse tree and is still small enough so one single person can have a pretty good overview of the entire thing. The same cannot be said of GCC.
As far as generic optimizers etc. are concerned, I've been thinking lately of adding a code generator backend which spits out LLVM code.
The primary criterium is that there is a compiler available which supports your target platform. Because you're comfortable with the language and are more productive using it that when using C or another language. If you aren't, nor see anything that entices you to learn it, by all means stay away from it as far as you can because using a language you don't like at all will only reduce your productivity (and your enjoyment of programming). I don't think you should, it would be hell to port that much software from one language to another. You can easily use all of those from within (new) Pascal programs though, should you want to. As someone else mentioned, FPC has been around since 1993. Not quite as old as GCC, but it's still respectable imp. We don't have contributors from IBM, Apple, ARM etc. Most professional contributors to FPC work in small companies that used Delphi until now, and they mostly contribute patches to the component libraries rather than to the compiler.I think the main reason for fpc's speed is simply that the compiler is much less complex (to the extent that a single person can still have a pretty good overview of pretty much the entire workings), while that cannot be said of gcc. And of course, fpc does a lot less passes over all the code.
At least Turbo Pascal and Free Pascal support range checking for subtypes. FPC also supports checking type casts from one object/class type to another. Most checks are only turned on for debug builds though, which is a big difference with Ada.
It keeps precompiled versions of interfaces, yes. But even when building from scratch, FPC is a lot faster than gcc. In general, gcc is simply a slow compiler (I've recently heard it does over 200 passes over each compiled function, so actually it is lightning fast relative to the work it does, but in absolute numbers it's still pretty slow (even with all optimizations turned off).
Probably not. FPC already had an internal i386 assembler, based on the tables of nasm. Those were simply extended for x86_64, iirc even based on beta patches to nasm. And the main reason for an internal linker was not x86_64 support, but the fact that ld is very slow and memory hungry (in particular on Windows). Also, by skipping all intermediate steps in the process of internal assembler representation -> text representation -> gas -> object files -> ld parsing object files again -> final binary, you obviously get an inherent speedup.
Both this internal assembler and linker are written in Pascal like the rest of the compiler, and therefore are much less work for the FPC team to write/test/debug than GNU as/ld (as most FPC developers are much more used to developing in Pascal than in C, not to mention that they know FPC inside out while this is not the case for the binutils).
That said, I'm personally also not a fan of duplicating functionality like that and will probably never do it for the FPC targets which I support, but I just wanted to correct your (wrong) notion that the people who wrote the internal assembler/linker could just as easily have added that support to the binutils.