Actually the cleanest way means more verbosity: you should use "const char *" if you want to assign string literals to pointers, and the return values of strlen() should be cached in variables, otherwise there will probably be duplicated work making the code slower than Java (In this case the compiler can, although most don't, figure out that the string C does not overlap with A or B because C is malloc'ed, so strlen(a) and strlen(b) won't change, but most of the time it can't, for example when you call some strange function in the middle). Thus C programs dealing with strings ARE very verbose if you don't want to use libraries.
However, using g_strdup_printf() in Glib (or asprintf() in GNU libc, but it isn't portable enough) will be a far easier option.
Maybe the number of people who will listen to such crappy music won't be too high, even if they only have to pay a very small amount of money. If the things come free people might spend some time hunting if they are bored, but paying money (even as low as $.01) is enough hassle in itself to discourage such hunting.
Books are pretty much uncopyable before Xerox machines are available (hand-copying does not count, since many copy-protected things actually can be copied without using outlawed equipments if you are willing to spend as much time as hand-copying), yet it seems natural that they are copyrightable if anything else is.
IMHO the only way out is still removing all legal protection to copy protection.
Yes, it is NIH syndrome. Besides, the word "Intellectual Property" has become a buzzword here in government-speak. The government strongly encourages companies to develop new IP, new standards (even if they are neither better or freer than others) and patent everything possible. They just don't care about free software at all, actually it is required that IP from government-sponsored projects are "sufficiently protected" (which mostly means "patented").
It is true that paying royalties to domestic companies is much better than paying foreigners (we all remember the DVD player fiasco), and it doesn't matter much whether ship-making (etc.) technologies are open or closed, but I don't think the current policies are suitable for software and related technologies. Mandating domestic proprietary (and sometimes incompatible) standards over existing free (as in freedom) ones may create more GDP in royalties, and possibly give domestic companies some advantage in competition (unlikely), but ordinary people actually loses.
Being a Chinese citizen, I think the situation here is similar to that in the US in 1970s as described by RMS. Basically most people are not aware of IP, and those who are getting to know it rush to "protect" it, few have yet to get the notion of free software(information, knowledge, etc.).
The normal python compiler compiles to portable bytecode. I think you need some software that translate that to native (machine) code. It is called psyco, hosted on sourceforge.net. I don't know about its current status though.
Also: something has always been broken
on
LSB & Posix Conflicts
·
· Score: 2, Informative
Other posts point out many good reasons (such as dumbness in POSIX, which should not be kept around in another standard), but for certain things (such as threads), the reason is that Linux at the time has not been conforming to POSIX in these aspects, so programmers are expected to pay special attention on Linux compatibility, rather than completely adhering to the POSIX standard, which may save a little effort but will break on many current Linux systems.
When most Linux systems conform to POSIX behavior on these aspects (for example by using NPTL for threads), the difference can be removed. Before then, programmers should try to make the program work in both POSIX systems and LSB systems.
PPro/P2/P3 should probably be the fastest Intel processor in terms of instructions per second. The first P2's at 233MHz (which I bought in Jan 1998 at a pretty hefty price and am still using now) didn't have much megahertz difference with Pentium MMX/200, but is just so much faster.
Since P4's have such a high frequency, it is impossible to still do everything as fast in terms of clock cycles. As far as I know, most non-vector integer applications run slower on a P4 than a P3 at the same clock frequency. Nothing surprising.
I think this thing has been discussed here before.
Also, Linus was advising developers that they don't look at patents, for if the kernel is hit by one of them (some are pretty broad), it would be much more trouble if the alleged patent infringement were done knowingly.
I suppose this is a reasonable tactic used by everyone, yet one can criticize it if he like.
I'm an EE major, and the teacher keeps saying, "If you graduated two year earlier, companies would literally fight for every one of you... But now...".
When I bought my first 386 in 1994 I can only program in Qbasic. I programmed a lot, and it is very interesting.
But BASIC is really awkward if you want to write structured, maintainable large programs. The largest Qbasic program I have ever written during the one or two years was about 5kB in source code.
Then I learned Pascal at school, and got hold of a copy of Turbo Pascal 5.5. In a month I switch to Pascal exclusively. Anyway, the programs look cleaner (well, clean for a kid's code, still much uglier than most OSS code or Borland's examples) and doing pretty graphics is just as easy. What's more, it is a compiled language, so it is a ton faster than Qbasic, and the Turbo Pascal compiler really lives up to its name, about 500-1000 lines/second even on a 386DX/40. I wrote quite a few 20kB+ (in source) programs doing various actually useful things. The biggest one is a complex RPG-like game, which is about 70kB in source code.
C was a hard language to learn by oneself, and although I spent quite a lot of time trying, I couldn't quite grasp it until it was taught in college (about 1999). Also, in DOS it is pretty easy to lock up the machine by using pointers incorrectly, which is scary, while in Pascal pointers are only occasionally necessary and there is range checking and stack checking, so bad things don't happen that often. However, comparing to C, Pascal's syntax looks awkward and verbose. In fact, C is also quite verbose, but the verbosity is about telling the machine the details about what to do, while Pascal's verbosity such as BEGIN and END doesn't mean anything. Also, when using complex data structures points should be used anyway, and Pascal's syntax IS awkward (type PFoo = ^TFoo...). So, since 1999, when I finally grokked C, has MSVC on Windows 95 and GCC on Linux, I dropped Pascal almost entirely.
In the last four years most of my programming are done in C, and most of the code is quite clean. I learned C++ too, but I didn't use it much because OOP was never really necessary for me, and I like Java better anyway (C++ has so many pitfalls, hides low-level details and makes debugging of pointer errors difficult, and there's too many ways to do something). I have tried Smalltalk, Ocaml, Lisp, Perl, Python too, but mostly just for small programs. For a long-time C programmer, It is hard to find a compelling reason to use something other than C (and Java) for a medium-sized project.
In the famous doom3 movie the nvidia people says that their GeForce3 (yes, that's several years ago) can do 79Gflops, so the current top-of-the-line gamers' graphics card can probably do much more. Yet the linpack benchmark says that P4 3.06GHz can do 1.4Gflops. Of course 3D graphics processing benefits greatly from MMX/SSE/SSE2, which may double the speed to something like 3Gflops, I don't think the P4 can do much more clock-for-clock.
So the best gamers' GPU now may have to be matched by a P4 well over 100GHz.
Stealing, as in depriving someone of certain physical property, is always illegal. However, depriving others of possible profit is legal by default (otherwise you cannot kill your competitor by making something better and costs less to make), it is the copyright law that makes a specific kind of such action (certain forms of copying copyrighted works) illegal.
So it is as specific as antitrust law or something similar. It is not a good idea to broaden it by making analogies of it with stealing.
In some cases GOTOs are very useful, especially in languages like C for error recovery. Look at the many "goto error"s in Linux Kernel code, they cannot look as good in any other C way. Of course in java you don't need to manually destruct things so often, so gotos are not that useful. Multi-level exits are also an important use for GOTO, and IMHO block labels are similar but less readable.
Also, some programs that does loops in irregular ways (such as non-recursive searching programs that backtracks) can be rewritten in a way that is much more readable IMHO. Alas, it is still as hard to make sure such code is correct, since you still have to follow every possible execution path, so it doesn't make the writer's life better.
Since my school is Windows-only and without latex, and I much preferred Linux at home (it runs much better as well, I just can't get that Win98 work completely right even with several reinstall attempts. Do I have to reformat?), I tried Oo.o (1.1beta2) to write my term paper, for it is supposed to be Word-compatible. Well, now that it is done, I have to say that it worked with much pain, and I really hoped I had used LaTeX instead --- at least it just works, and it is hard to lose data in plain text files.
Oo.o by itself works reasonably decently, but it does have a nasty habit of losing embedded images. I work around this problem by linking them.
I have to type a lot of equations, and OoMath mostly works, although it is quite unintuitive. It also have quite a few annoying bugs (or misconfiguration? but I have tried hard enough.) like bad square roots.
Importing Word files (like certain standards) also mostly works, yet some defaults (like text grid) are set wrongly, so I have to fix them before some documents will look right. Also some Mathtype equations are not converted correctly.
Oo.o is also a big monster for my P2/233 with 128MB of memory. It takes one minute or so to start, and loading/saving are slow, which means I can barely auto-save, which is bad.
Anyway, writing in Oo.o isn't that bad. It is buggy, but most bugs can be worked around, and Word has many bugs (or annoying things) too. It is when exporting the files as Word ones that caused major pain.
I chose to convert the equations to MathType so that I can edit them in Word, and after opening the files in Word for win98 system resources started to drain like mad and it is just impossible to do anything serious. Normal DOC files opens okay, so it must be that the DOC files generated by Oo.o are strange enough to crash Word. Then I tried to open the resulting files on the schools' WinXP machines. Of course no more resource problems, but MathType still crashes often, so the files ARE probably problematic. Although it is in some way MS's fault too for giving strange behavior on strange input.
So I turned off Oomath->mathtype conversion. The resulting files still cause resource drains on win98, but open okay on Word for WinXP. Yet the math symbols become low-resolution bitmaps that look just too nasty. Frustrated, I replaced all OoMath stuff with Mathtype. Cost me two hours for 14 pages full of equations.
After this the remaining problems are mostly minor. One is that OoDraw doesn't get the line widths right if it is the default 0.01cm, when exporting as either EPS or WMF. 0.02cm lines are right, but 0.01cm lines just became 0.001cm ones in the EPS files. So I just made the lines 0.02cm and hacked the resulting EPS files. Another problem is some table cells become very large in Word, and I don't know why, so I just fixed that with Table->Text->Table. Finally some italic text (used as poor man's equation) becomes regular.
Last but not least, Oo.o occasionally becomes very unresponsive on Linux. Even after patching out sched_yield with a LD_PRELOAD library. It looks like some other problem.
The morals for this story: if you want to do your term papers on linux, it is a much safer bet using LaTeX. Openoffice mostly works, but expect some nasty things for now, especially for Word compatibility. Of course I hope developers will see this story too, although I have reported most of these problems as bugs. Alas, the problem of exporting Word-crashing DOC files seems to be pretty hard to debug...
As for why I have to use a beta version... Anything 1.0.x doesn't support Chinese decently.
It is really pathetic if people are afraid of publishing their phone numbers or email addresses for fear of spam. At least, it should be made sure that one can safely make his phone number known to all without causing him any direct monetary or mental (obscene jokes anyone?) harm. He may just waste some time shuffling around.
So I suggest the following things to be done:
You shouldn't be charged for receiving SMS. Of course, there can be some receiver-paid SMS services for the situations where this is needed, but then the receiver's permission would be required. Of course this way fee distribution between operators may become more complex, but I'm quite sure such problems can be worked out if there's an incentive.
Mobile phones should allow people to preview the messages prior to actually reading them, where "preview" means "looking at the caller's number". In this way offensive spam can be avoided if one wants to.
Make sure you won't pay money unknowingly. Here in China there are often stories about people who received a message like "you are now subscribed in service XXX. First month is free, then it costs XXX/month", without knowingly doing anything. Opt-out can be sometimes harder than it seems (delicate differences between similar services, etc.). Many people even don't know what is happening when their mobile phone bills contains some extra items they don't understand (yes, most such services are charged this way). Things like making me pay on my phone bill should really be strictly regulated.
If VMWare is not tested on a particular kernel, it probably won't work.
Really. VMWare runs well on supported kernels, but always has some kinds of problems if I recompile the kernel module and run it with something else, such as a custom kernel.
In the FAQ about "why it has no data journaling" you say that it would still break if one file is updated while another isn't. However in many cases it is a heap better to have the file intact (one version or another) than have its contents garbled (so nothing remains unless you search in the raw partition). Also, while it is true that some user-level applications will break if two files are not updated simultaneously, this is much fewer than the applications that will choke on garbled files.
It is true that even Ext3's ordered data mode cannot absolutely prevent breakage during a power loss, but keep the probability of lossage low is also important. It is impractical to backup my term papers every minute, and the lower the chance of losing one day's work (or more if I forgot to backup yesterday) because of a power loss (because of garbled content... I do save every minute), the better.
There are some problems with my power supply, causing my computer to lose power for about twice a week. Like most desktop computers, it has no UPS.
When using ReiserFS I often find some newly-(over)written files contain garbled content after a power loss. Filesystem integrity is okay according to reiserfsck. When using Ext3 such problems don't happen that often. From what I have read, this is because ReiserFS does metadata journaling like Ext3's "metadata" mode, while Ext3 uses "ordered" mode by default, which prevents writing metadata before the actual data that may cause garbage to show up if a power failure happen in between ("in between" can sometimes mean a minute or so).
The question is: will reiserfs support something like Ext3's ordered mode? Otherwise, it is quite unsafe to store frequently modified files (like those in the home directory) on ReiserFS partitions, if power failures happen often.
Well, it is XEmacs to be exact. MULE-UCS works just fine for editing UTF-8 Chinese text. Only needs to call (un-define-change-charset-order...) to use Chinese fonts for Chinese character, instead of the Japanese fonts, which shows the same characters but doesn't look pretty for a Chinese person.
Slashdot Mirror
However, using g_strdup_printf() in Glib (or asprintf() in GNU libc, but it isn't portable enough) will be a far easier option.
Maybe the number of people who will listen to such crappy music won't be too high, even if they only have to pay a very small amount of money. If the things come free people might spend some time hunting if they are bored, but paying money (even as low as $.01) is enough hassle in itself to discourage such hunting.
IMHO the only way out is still removing all legal protection to copy protection.
It is true that paying royalties to domestic companies is much better than paying foreigners (we all remember the DVD player fiasco), and it doesn't matter much whether ship-making (etc.) technologies are open or closed, but I don't think the current policies are suitable for software and related technologies. Mandating domestic proprietary (and sometimes incompatible) standards over existing free (as in freedom) ones may create more GDP in royalties, and possibly give domestic companies some advantage in competition (unlikely), but ordinary people actually loses.
Being a Chinese citizen, I think the situation here is similar to that in the US in 1970s as described by RMS. Basically most people are not aware of IP, and those who are getting to know it rush to "protect" it, few have yet to get the notion of free software(information, knowledge, etc.).
The normal python compiler compiles to portable bytecode. I think you need some software that translate that to native (machine) code. It is called psyco, hosted on sourceforge.net. I don't know about its current status though.
When most Linux systems conform to POSIX behavior on these aspects (for example by using NPTL for threads), the difference can be removed. Before then, programmers should try to make the program work in both POSIX systems and LSB systems.
This file is usually statically-linked, and can be used instead of RPM to install packages in case of emergency.
I once traced sendmail's source code. Absolutely messy.
Since P4's have such a high frequency, it is impossible to still do everything as fast in terms of clock cycles. As far as I know, most non-vector integer applications run slower on a P4 than a P3 at the same clock frequency. Nothing surprising.
If you want to import the file as raster content, just use "convert" in ImageMagick to convert it into a raster format such as PNG first.
Well, with most cellphones here, one needs to type the encrypted message onto a computer to decrypt it. They aren't long, anyway.
Of course key exchanging has to be done using regular methods.
I'm in China using a Chinese free mail service. There isn't much spam (2/week), but 70% of which is about FaLunGong.
Also, Linus was advising developers that they don't look at patents, for if the kernel is hit by one of them (some are pretty broad), it would be much more trouble if the alleged patent infringement were done knowingly.
I suppose this is a reasonable tactic used by everyone, yet one can criticize it if he like.
I suspect the resulting ice cream wouldn't taste so well with these brown things. It isn't that cold, either.
I'm an EE major, and the teacher keeps saying, "If you graduated two year earlier, companies would literally fight for every one of you... But now...".
But BASIC is really awkward if you want to write structured, maintainable large programs. The largest Qbasic program I have ever written during the one or two years was about 5kB in source code.
Then I learned Pascal at school, and got hold of a copy of Turbo Pascal 5.5. In a month I switch to Pascal exclusively. Anyway, the programs look cleaner (well, clean for a kid's code, still much uglier than most OSS code or Borland's examples) and doing pretty graphics is just as easy. What's more, it is a compiled language, so it is a ton faster than Qbasic, and the Turbo Pascal compiler really lives up to its name, about 500-1000 lines/second even on a 386DX/40. I wrote quite a few 20kB+ (in source) programs doing various actually useful things. The biggest one is a complex RPG-like game, which is about 70kB in source code.
C was a hard language to learn by oneself, and although I spent quite a lot of time trying, I couldn't quite grasp it until it was taught in college (about 1999). Also, in DOS it is pretty easy to lock up the machine by using pointers incorrectly, which is scary, while in Pascal pointers are only occasionally necessary and there is range checking and stack checking, so bad things don't happen that often. However, comparing to C, Pascal's syntax looks awkward and verbose. In fact, C is also quite verbose, but the verbosity is about telling the machine the details about what to do, while Pascal's verbosity such as BEGIN and END doesn't mean anything. Also, when using complex data structures points should be used anyway, and Pascal's syntax IS awkward (type PFoo = ^TFoo...). So, since 1999, when I finally grokked C, has MSVC on Windows 95 and GCC on Linux, I dropped Pascal almost entirely.
In the last four years most of my programming are done in C, and most of the code is quite clean. I learned C++ too, but I didn't use it much because OOP was never really necessary for me, and I like Java better anyway (C++ has so many pitfalls, hides low-level details and makes debugging of pointer errors difficult, and there's too many ways to do something). I have tried Smalltalk, Ocaml, Lisp, Perl, Python too, but mostly just for small programs. For a long-time C programmer, It is hard to find a compelling reason to use something other than C (and Java) for a medium-sized project.
So the best gamers' GPU now may have to be matched by a P4 well over 100GHz.
So it is as specific as antitrust law or something similar. It is not a good idea to broaden it by making analogies of it with stealing.
Also, some programs that does loops in irregular ways (such as non-recursive searching programs that backtracks) can be rewritten in a way that is much more readable IMHO. Alas, it is still as hard to make sure such code is correct, since you still have to follow every possible execution path, so it doesn't make the writer's life better.
Oo.o by itself works reasonably decently, but it does have a nasty habit of losing embedded images. I work around this problem by linking them.
I have to type a lot of equations, and OoMath mostly works, although it is quite unintuitive. It also have quite a few annoying bugs (or misconfiguration? but I have tried hard enough.) like bad square roots.
Importing Word files (like certain standards) also mostly works, yet some defaults (like text grid) are set wrongly, so I have to fix them before some documents will look right. Also some Mathtype equations are not converted correctly.
Oo.o is also a big monster for my P2/233 with 128MB of memory. It takes one minute or so to start, and loading/saving are slow, which means I can barely auto-save, which is bad.
Anyway, writing in Oo.o isn't that bad. It is buggy, but most bugs can be worked around, and Word has many bugs (or annoying things) too. It is when exporting the files as Word ones that caused major pain.
I chose to convert the equations to MathType so that I can edit them in Word, and after opening the files in Word for win98 system resources started to drain like mad and it is just impossible to do anything serious. Normal DOC files opens okay, so it must be that the DOC files generated by Oo.o are strange enough to crash Word. Then I tried to open the resulting files on the schools' WinXP machines. Of course no more resource problems, but MathType still crashes often, so the files ARE probably problematic. Although it is in some way MS's fault too for giving strange behavior on strange input.
So I turned off Oomath->mathtype conversion. The resulting files still cause resource drains on win98, but open okay on Word for WinXP. Yet the math symbols become low-resolution bitmaps that look just too nasty. Frustrated, I replaced all OoMath stuff with Mathtype. Cost me two hours for 14 pages full of equations.
After this the remaining problems are mostly minor. One is that OoDraw doesn't get the line widths right if it is the default 0.01cm, when exporting as either EPS or WMF. 0.02cm lines are right, but 0.01cm lines just became 0.001cm ones in the EPS files. So I just made the lines 0.02cm and hacked the resulting EPS files. Another problem is some table cells become very large in Word, and I don't know why, so I just fixed that with Table->Text->Table. Finally some italic text (used as poor man's equation) becomes regular.
Last but not least, Oo.o occasionally becomes very unresponsive on Linux. Even after patching out sched_yield with a LD_PRELOAD library. It looks like some other problem.
The morals for this story: if you want to do your term papers on linux, it is a much safer bet using LaTeX. Openoffice mostly works, but expect some nasty things for now, especially for Word compatibility. Of course I hope developers will see this story too, although I have reported most of these problems as bugs. Alas, the problem of exporting Word-crashing DOC files seems to be pretty hard to debug...
As for why I have to use a beta version... Anything 1.0.x doesn't support Chinese decently.
So I suggest the following things to be done:
Really. VMWare runs well on supported kernels, but always has some kinds of problems if I recompile the kernel module and run it with something else, such as a custom kernel.
It is true that even Ext3's ordered data mode cannot absolutely prevent breakage during a power loss, but keep the probability of lossage low is also important. It is impractical to backup my term papers every minute, and the lower the chance of losing one day's work (or more if I forgot to backup yesterday) because of a power loss (because of garbled content... I do save every minute), the better.
When using ReiserFS I often find some newly-(over)written files contain garbled content after a power loss. Filesystem integrity is okay according to reiserfsck. When using Ext3 such problems don't happen that often. From what I have read, this is because ReiserFS does metadata journaling like Ext3's "metadata" mode, while Ext3 uses "ordered" mode by default, which prevents writing metadata before the actual data that may cause garbage to show up if a power failure happen in between ("in between" can sometimes mean a minute or so).
The question is: will reiserfs support something like Ext3's ordered mode? Otherwise, it is quite unsafe to store frequently modified files (like those in the home directory) on ReiserFS partitions, if power failures happen often.
Well, it is XEmacs to be exact. MULE-UCS works just fine for editing UTF-8 Chinese text. Only needs to call (un-define-change-charset-order ...) to use Chinese fonts for Chinese character, instead of the Japanese fonts, which shows the same characters but doesn't look pretty for a Chinese person.