When doing things manually this should be quite clear. If you want to try out some executable from an unknown source (assuming the system contains no local root exploits), run it as some "nobody"-like account, not as your own account or root.
I think email clients and web browsers should also temporarily change uid to "nobody" when processing the data received.
The problem is that you can't do that currently unless the email client itself is run as root (or have CAP_SETUID). Of course you may have the setuid bit set on the email client executable, but then local security becomes harder to manage, and many useful functionality (core dumping and LD_PRELOAD'ing, etc.) are lost. Maybe we should have a "trusted uid" idea, so that user "foo" can have another uid "foonobody" that has as little priviledge as "foo" wants, and when the euid is "foo", "foonobody" is seen as the same user when determining priviledges, so a program running as "foo" can access foonobody's files, do setuid(foonobody), chmod a file owned by foonobody, chown a file to foonobody (they are the same user, so the usual chown-as-root restrictions shouldn't apply), and so on (but not vice versa). Then an email client runned by "foo" can setreuid to "foonobody" (according to a config file) when processing the HTML/attachment, and setreuid back when done (the real uid was still "foo" --- but the more secure solution is to end the thread after processing is finished).
One problem is left though. The attachment processing probably shouldn't be running in the same thread (otherwise malicious programs may corrupt the part owned by "foo"), and if the processing result needs to be communicated back to the email program, the email program will have to do a lot of verification. HTML renderers can be made to render in an X window directly though.
I don't see how the grandparent poster can't do the same as his friends have done to him, in some other fields (such as wine) he is more interested in. Then it is a fair game.
Indeed, whether it's web sites or OSS software, the average consumer/producer ratio tends to be very high (if not, the producer will probably want free-riders, so it is not relevent to this problem), so everyone only have to contribute a very small amount to balance the system.
By the way, I don't like calling people "parasites" just because you understand his posts in a more radical way.
If the seller don't want people to modify their stuff, they should make the buyer sign a contract when doing the sale. It is definitely unfair for the customer (even if legal) if they use click-through EULAs or unknown-by-joe-public laws such as DMCA.
Will we have a library nightmare?
on
AMD64 Preview
·
· Score: 2, Interesting
For optimal performance and compatibility, we need at least three sets of libraries: a pure 32-bit version (old apps have to run in 32-bit mode with a 64-bit kernel because the new instruction set is not entirely compatible with the old one), a "small" 64-bit version in which pointers are 32-bit in memory (so that most applications can get 64-bit and the extra registers, etc., without wasting memory on pointers), and a regular 64-bit version for the apps that really need the large address space. Seems that the nightmares of tiny/small/medium/large/huge/compact memory models in 16-bit x86 will come again.
Anyway, those running other existing 64-bit CPUs should be able to give some advice.
If what the cracker did is actually what this post says, I think he didn't do anything wrong ethically. There is really few alternatives if you do want to get the system fixed and the admin isn't that friendly.
But anyway he clearly violated the law, so it is mostly fair (albeit pathetic) that he gets prosecuted. He must be either very brave or stupid (or both) to do such things knowingly. Once I want to blame the law, but anyway there is already plenty of ethical ways to break the law badly.
Maybe the law should be amended so that the cracker will not have jailtime if he can prove that his intentions are good, and no actual damages are done.
Why do you think that he is buying the top-of-the-line model of Opteron? Since he seems to be saving money, he must be going for the ones with a slightly lower clock speed, which costs a LOT less.
Also remember that the performance of 2GHz G5s and 2GHz (or any other version) Opterons are not readily comparable.
The semiconductor industry also have VERY deep pockets. Considering that a modern silicon fab costs several billions of dollars, anyone who can afford a number of these can have a pretty fight with DeBeers if the latter want to pick a fight.
In the CPU core (the part inside the xxx-pin package), the substrate (the main part) is lightly doped silicon (quite pure when not used in semiconductors) that has little electrical purposes. It serves mostly to increase the mechanical strength of the core. The actual circuit is built upon that, containing for example heavily-doped silicon (which is not-very-pure silicon), copper and polysilicon interconnects, SiO2 insulation layers, etc. It's definitely not pure silicon.
For diamond CPUs, maybe it is just similar kinds of circuits on a (possibly doped) diamond substrate. It is not a pure diamond, although the substrate might be purer than most natural diamonds.
I'm no economist, but it seems obvious that software that are mostly free-as-in-beer don't increase GDP in distribution, but payware do. Not that it actually matters, of course.
My linux box receives 10kB/s worth of packets even when idle (ordinarily this number is less than 1kB/s). Ethereal says that most of them are ARP packets, the rest are pings and port 135 requests. Guess they are related.
Most countries impose restrictions on importing a few kinds of goods, and the blacklist in China isn't really long. However if China can only blacklist one thing, it will probably be grain or something similar --- just because the lives of the farmers are more important than the PR for allowing free trade, and farmer's productivity can't be quickly improved, neither can the government get a lot of the farmers employed in factories anytime soon. Anyway, I have heard that U.S. farmers get government subsidies, if it is true the competition is unfair anyway.
Other countries' restrictions on import are often due to similar reasons. These should be understood.
According to the GNU website, "Linux" means just the kernel, so if the kernel got replaced the system is not GNU/Linux any more. It may be called GNU/Hurd, or "The GNU system" (which is also more or less usable now).
As for "used memory" keeping increasing... You just have way too much memory. On most machines "used memory" is almost equal to "total memory" while the system runs fine, because the memory not used by processes can be used for caching (and not just the "Cached" shown by top/free, either). In short, it is hard to know whether or not the kernel or a user process leaks or not just by looking at the memory statistics, even if there actually IS one.
If you suspect a leak in some process, look at its VM size. If there is a leak, the process will end up much larger after repeating some operation, such as opening a new window, N times (clean up after each time) than doing that once.
Another way is to look at the swap usage. It usually keeps increasing, but should mostly be stable after e.g. 2 hours of usage, unless you start some other very large applications.
I think they are fragile
on
The Diamond Age
·
· Score: 3, Informative
Diamonds are IMHO extremely fragile. Would you want to use a glass knife to cut pork? If you are a little bit less than careful it would break and hurt you. If the bottom of a frying pan is fragile you will have a hard time moving stuff around in it. I guess diamond cookware would have the same disadvantages.
On linux the best looking fonts are anti-aliased TrueType, which Swing doesn't support. Bitmap fonts also look good when not scaled, but it is also very non-obvious (if not impossible) to make them the default in Swing apps. So we are left with ugly non-antialiased TrueType fonts. Ugh!
(Well, maybe it is the fonts that are not as good as Windows fonts... But if you want to work with international text, even Window's unantialiased non-bitmap Chinese fonts look VERY ugly.)
If you are developing a cross-platform high-level GUI application, just use toolkits. You don't need the flexibility of Xlib.
However, for those developing low-level X programs such as window managers and XIM servers that need to meddle with (say) ICCCM details, you are probably better off just using Xlib --- just like programs doing low-level I/O are better off using low-level functions instead of stdio.
Note that even in some cross-platform applications some non-portable stuff is needed in order to tune user experience, for example you may find a cool new feature of recent window managers accessible via ICCCM beneficial (albeit not essential) to your application, but toolkits haven't integrated such things yet. Therefore, it is very important that toolkits give access to low-level things like Window/Atom/Pixmap IDs so that bypassing it occasionally is possible. I don't know about others, but GTK does well in this regard.
This is NOT dead code removal
on
GCC 3.3.1 Released
·
· Score: 4, Insightful
Your problem is that glibc does so much initialization upon startup that a lot of code, such as printf(), (might) get used by that, so the linker have to include them in the statically linked executable. If this can be fixed, it is glibc that should be fixed to avoid unnecessary internal dependencies.
Also, compared to libgcj, glibc's contribution of executable size is quite small (about 300~400k), so maybe optimizing libgcj is more important.
Dead code removal means that part of the source code that will never be executed (as decided by the compiler) will not turn into executable code. For the simplest example, in "if (0) {... }" the whole statement will be skipped in executable code. Sometimes it is harder, for example "a = foo(); if (a == null) a = this; BLAH BLAH BLAH; if (a == null) {... }".
I think for "Stability" you mean "Robustness", so that data loss can be avoided in a power outage or other out-of-spec situations (things supposed to be fixed with data journaling, atomic transactions, etc.), while I mean "lack of Bugs". It is true that robustness is a problem that should be figured out at design time and it can be more important than speed, but I think the original poster means unbugginess for stability. Anyway, reiser4, ext3 (ordered/data journaling mode) are robust enough, but the former is new and buggy.
Stability bugs will be fixed if the performance is good enough, but speed problems can be hard to fix without altering the most basic things about a filesystem.
Currently I still don't trust online payment that much, because if enough information is leaked I may lose a lot of money even if I don't lose anything (such as the credit card) physically. Paying via traditional means is safer but means much more hassle. Of course for ISP-provided content they can include the fees in the bill, and I trust them well enough, but my ISP doesn't provide much content.
Another problem is that most things I want to purchase online are physical goods such as USB mice, books, movies, etc., which have to be physically sent to me with some means, causing inconvenience (I must be home at 4pm, or I must remember to retrieve my mail package) and increasing cost. Electronic books are significantly less portable (because a computer is required) than real books even in a free format (plain text, HTML, ordinary PDF), they are even more inconvenient when DRM'ed (possibly Windows-only for example), so I'm willing to pay much less for them.
BTW, before anyone mods me offtopic, aren't books and movies "content" as meant by the author?
I have heard that P4 runs code compiled for i386/P2/P3 rather slowly compared to code compiled for it. For example, P4 runs traditional (stack-based) FPU instructions rather slowly, while it prefers SSE/SSE2-based instructions. Therefore on P4 systems compiling with the right options may well give a significant speed boost.
However, AFAIK PPro/P2/P3/Athlon runs these "legacy" code quite well, so relatively little gain can come from compiler option tweakings.
Especially when you link to a lot of libraries, dynamic linking can often take a lot of milliseconds. Prelinking helps a bit, but static linking is the fastest. On my machine running a simplest program takes 5ms when dynamically linked, 3ms when statically linked, "user time" is 1.1ms vs. 0.4ms.
Slashdot Mirror
I think email clients and web browsers should also temporarily change uid to "nobody" when processing the data received.
The problem is that you can't do that currently unless the email client itself is run as root (or have CAP_SETUID). Of course you may have the setuid bit set on the email client executable, but then local security becomes harder to manage, and many useful functionality (core dumping and LD_PRELOAD'ing, etc.) are lost. Maybe we should have a "trusted uid" idea, so that user "foo" can have another uid "foonobody" that has as little priviledge as "foo" wants, and when the euid is "foo", "foonobody" is seen as the same user when determining priviledges, so a program running as "foo" can access foonobody's files, do setuid(foonobody), chmod a file owned by foonobody, chown a file to foonobody (they are the same user, so the usual chown-as-root restrictions shouldn't apply), and so on (but not vice versa). Then an email client runned by "foo" can setreuid to "foonobody" (according to a config file) when processing the HTML/attachment, and setreuid back when done (the real uid was still "foo" --- but the more secure solution is to end the thread after processing is finished).
One problem is left though. The attachment processing probably shouldn't be running in the same thread (otherwise malicious programs may corrupt the part owned by "foo"), and if the processing result needs to be communicated back to the email program, the email program will have to do a lot of verification. HTML renderers can be made to render in an X window directly though.
IANAL, but IIRC in many countries money obtained through ATM malfunction is not technically yours, and you must return them.
One reference implementation of Djvu is OSS, so it is definitely an open format.
Indeed, whether it's web sites or OSS software, the average consumer/producer ratio tends to be very high (if not, the producer will probably want free-riders, so it is not relevent to this problem), so everyone only have to contribute a very small amount to balance the system.
By the way, I don't like calling people "parasites" just because you understand his posts in a more radical way.
If the seller don't want people to modify their stuff, they should make the buyer sign a contract when doing the sale. It is definitely unfair for the customer (even if legal) if they use click-through EULAs or unknown-by-joe-public laws such as DMCA.
Anyway, those running other existing 64-bit CPUs should be able to give some advice.
But anyway he clearly violated the law, so it is mostly fair (albeit pathetic) that he gets prosecuted. He must be either very brave or stupid (or both) to do such things knowingly. Once I want to blame the law, but anyway there is already plenty of ethical ways to break the law badly.
Maybe the law should be amended so that the cracker will not have jailtime if he can prove that his intentions are good, and no actual damages are done.
Also remember that the performance of 2GHz G5s and 2GHz (or any other version) Opterons are not readily comparable.
The semiconductor industry also have VERY deep pockets. Considering that a modern silicon fab costs several billions of dollars, anyone who can afford a number of these can have a pretty fight with DeBeers if the latter want to pick a fight.
For diamond CPUs, maybe it is just similar kinds of circuits on a (possibly doped) diamond substrate. It is not a pure diamond, although the substrate might be purer than most natural diamonds.
I'm no economist, but it seems obvious that software that are mostly free-as-in-beer don't increase GDP in distribution, but payware do. Not that it actually matters, of course.
My linux box receives 10kB/s worth of packets even when idle (ordinarily this number is less than 1kB/s). Ethereal says that most of them are ARP packets, the rest are pings and port 135 requests. Guess they are related.
Other countries' restrictions on import are often due to similar reasons. These should be understood.
According to the GNU website, "Linux" means just the kernel, so if the kernel got replaced the system is not GNU/Linux any more. It may be called GNU/Hurd, or "The GNU system" (which is also more or less usable now).
If you suspect a leak in some process, look at its VM size. If there is a leak, the process will end up much larger after repeating some operation, such as opening a new window, N times (clean up after each time) than doing that once.
Another way is to look at the swap usage. It usually keeps increasing, but should mostly be stable after e.g. 2 hours of usage, unless you start some other very large applications.
Diamonds are IMHO extremely fragile. Would you want to use a glass knife to cut pork? If you are a little bit less than careful it would break and hurt you. If the bottom of a frying pan is fragile you will have a hard time moving stuff around in it. I guess diamond cookware would have the same disadvantages.
(Well, maybe it is the fonts that are not as good as Windows fonts... But if you want to work with international text, even Window's unantialiased non-bitmap Chinese fonts look VERY ugly.)
However, for those developing low-level X programs such as window managers and XIM servers that need to meddle with (say) ICCCM details, you are probably better off just using Xlib --- just like programs doing low-level I/O are better off using low-level functions instead of stdio.
Note that even in some cross-platform applications some non-portable stuff is needed in order to tune user experience, for example you may find a cool new feature of recent window managers accessible via ICCCM beneficial (albeit not essential) to your application, but toolkits haven't integrated such things yet. Therefore, it is very important that toolkits give access to low-level things like Window/Atom/Pixmap IDs so that bypassing it occasionally is possible. I don't know about others, but GTK does well in this regard.
Also, compared to libgcj, glibc's contribution of executable size is quite small (about 300~400k), so maybe optimizing libgcj is more important.
Dead code removal means that part of the source code that will never be executed (as decided by the compiler) will not turn into executable code. For the simplest example, in "if (0) { ... }" the whole statement will be skipped in executable code. Sometimes it is harder, for example "a = foo(); if (a == null) a = this; BLAH BLAH BLAH; if (a == null) { ... }".
I think for "Stability" you mean "Robustness", so that data loss can be avoided in a power outage or other out-of-spec situations (things supposed to be fixed with data journaling, atomic transactions, etc.), while I mean "lack of Bugs". It is true that robustness is a problem that should be figured out at design time and it can be more important than speed, but I think the original poster means unbugginess for stability. Anyway, reiser4, ext3 (ordered/data journaling mode) are robust enough, but the former is new and buggy.
Stability bugs will be fixed if the performance is good enough, but speed problems can be hard to fix without altering the most basic things about a filesystem.
Another problem is that most things I want to purchase online are physical goods such as USB mice, books, movies, etc., which have to be physically sent to me with some means, causing inconvenience (I must be home at 4pm, or I must remember to retrieve my mail package) and increasing cost. Electronic books are significantly less portable (because a computer is required) than real books even in a free format (plain text, HTML, ordinary PDF), they are even more inconvenient when DRM'ed (possibly Windows-only for example), so I'm willing to pay much less for them.
BTW, before anyone mods me offtopic, aren't books and movies "content" as meant by the author?
However, AFAIK PPro/P2/P3/Athlon runs these "legacy" code quite well, so relatively little gain can come from compiler option tweakings.
Especially when you link to a lot of libraries, dynamic linking can often take a lot of milliseconds. Prelinking helps a bit, but static linking is the fastest. On my machine running a simplest program takes 5ms when dynamically linked, 3ms when statically linked, "user time" is 1.1ms vs. 0.4ms.