The government asks for blocking nazi websites. This is a smart move, as the great majority of Germans is in favor of making the distribution
of such material illegal. At least some providers, especially smaller ones, will block the content as soon as the goverment threatens to sue
them, since not doing so would result in bad PR. The question is, will they stop here? I'm quite sure the next thing to be blocked will be
content that is "not appropriate for children." Will they stop there?
+
Bullshit. This is not based on a new law, it's just a technical implementation. Nazi propaganda has been illegal for over fifty years in Germany, and the government has, by and large, stopped there. It's not the beginning of a "slippery slope".
Your way of thinking is unfortunately uninformed and flawed.
These kinds of restrictions were installed by the AMERICAN occupation government in order to get Germany AWAY from its Nazi past, they're just now being implemented for the Internet in the samy way that they have been implemented for the conventional press for over fifty years. Germans have just found this restriction to be quite sensible and have kept it.
In fact, Germans have freer speech than Americans in many ways. Please take off your starred and striped glasses and see the world as it really is. The USA is not any more a "bastion of freedom" than a large number of other countries, and it shows amazing amounts of hypocrisy to talk about freedom while having actively supported and funded many of the most opressive tyrannies during the last 100 years.
I suppose you got that "real history" from one of the sites whose DNS entries are being changed? Because it is total, utter bullshit. The murederous hatred for Jews is perfectly obvious in Hitler's writing years before he came into power. And the Nazi's "promotion" of science was a joke, they promoted only things that were either usable for the war effort or propaganda, or which one of the leaders had taken a facny to. In the latter two cases, the "science" was often a total joke (e.g. the "racial science"). And of course, some of the best scientists were disparaged or even killed because they were Jews.
Sure, that's the smart way, and that's what I'd do - for everybody (It's also how SuSE does it). I really don't see why PATH=/bin:/usr/bin (you would add/bin, yes?) should be the default. Admittedly, anyone using the command line preferrentially would probably know why and how to change PATH, but why not spare them the hassle?
No, never used a Mac. Do they actually do this when saving text as PLAIN TEXT? I doubt it, otherwise I don't think that character set would be called "Windows-"
Or could it be that other plants could do the same job, but also have the same problem and are thus not considered? It doesn't work, so who gives a fuck why one of them is also not considered for other reasons? I mean, being against overzealous drug legislation is one thing, but portraying hemp as a solution to all our problems is just as dumb.
Putting some of the largest applications (such as KDE) into separate trees certainly makes sense, but I (and many others) prefer to lauch graphical apps from the command line, so not having them in the PATH is completely unacceptable.
Sounds different to "Put everything in separate folders, then link what you need, which is what I was arguing against. And sounds like an awful lot of work for the benefit of "clean" disks (for a highly arguable definition of "clean").
Because I know the exact source of the problem: Microsoft decided that right and left double quotes must look different (which is not so bad an idea) and wrote their programs to use a proprietary, non-standard extension of the ASCII characters in order to preserve this difference when operating on plain text (which is). While they were at it, they included the apostrophe and a few other characters.
Additional questionoid: how much of the surface of the earth would need ot be converted to hemp to actually take care of '99% of our energy needs'? Where would we plant food?
No, the symlink requires one extra disk seek, possibly two if the link text is too large to fit into the link's inode. And absolute paths won't help at all, not if you insist on symlinking everything.
Think disk seeks, please. Scanning 20 small directories takes almost 20 times as long as scanning one large one. And it's a matter of several million CPU cycles.
Um, the point of chroot is that you have ONE 'fake' root, and the chrooted program can't access anything outside. So do you want the program to be chrooted into its own directory and unable to write any user-specific data, or chrooted to the user's directory, requiring the ENTIRE system to be hardlinked there? Or am I misunderstanding something?
"Could you help me please? You see, I just wrote this new shell script, and the shell says it can't find it, but I didn't mistype it, and I did set the executable bit..."
Imagine the above, 5 times a day, in greatly varying shades of cluefulness and politeness...
Sorry, but disk seeks take time in the millisecond range, and it's not something that has gotten much faster with recent disks. And it's NOT only one disk seek when you add in shared libraries, configuration and data files, and possibly access to other applications with which the program interfaces. For a large application, it could make the difference between a startup time of 5 seconds and 10 seconds, which is quite a lot.
The cache doesn't work for negative results (i.e. typos), except when you make it so that a new executable won't be found until you tell the shell to rebuild the cache, in which case it will THEN do an exhaustive scan. Not as bit a performance problem, but a pretty braindead design. How often do you want to tell a newbie why the shell can't find his new shell script?
That's because Mozilla apparently contains a bugfix for Mocrosoft's non-standard ASCII extension. Netscape 4.7 doesn't, and I'm afraid the Sparc version of Mozilla is too damn bloeated to use. Besides, it's no excuse for using a broken charset that some browsers will fix it.
OK, so let's say it really IS that good, and they don't have to buy your support.
Doesn't happen. We're talking about HUGE systems that are custom built for each customer and need constant modification adn extension, over decades. Open-sourcing the components from which they are built makes very little difference, as much more work and money goes into the building process, which is different for each customer.
Dunno the details, but that works only for positive results, not negative ones, right? So each typo still causes an exhaustive search. That, or you'd have to tell the shell explicitly to do it after adding a new executable.
No, and it wouldn't help, because it would still force the system to go through ALL those directories to find an executable in some cases (especially for a typo). In fact, it would be much, MUCH worse than hundreds of entries in PATH, because it would cause a lot of directories to be scanned that don't even contain binaries at all.
Dunno about you, but I hardly ever launch programs through menus and never through desktop icons. If you work at the command line most of the time because of its greater flexibility, having to grab the mouse and wading through a menu or minimizing all the windows in front of a desktop icon just to start a program is actually much SLOWER than typing in the name.
Um... You still want to RUN those applications, yes? And you don't want to remember and type in the full path for 2000 executables, yes? So you want your shell to find the executables for you. Which is what the PATH variable is for.
Um... have you read the article? That's exactly the claim the author makes, and it's not even exaggerated much. At my university's system,/usr/local/dist/bin contains 1476 files. Even if each application accounts for several of them, that still means a few hundred applications, and a few hundred PATH entries would KILL the system, because each of these directories would have to be scanned to find an executable, which is a few dozen times slower than scanning only a few large directories.
Slashdot Mirror
of such material illegal. At least some providers, especially smaller ones, will block the content as soon as the goverment threatens to sue
them, since not doing so would result in bad PR. The question is, will they stop here? I'm quite sure the next thing to be blocked will be
content that is "not appropriate for children." Will they stop there?
+
Bullshit. This is not based on a new law, it's just a technical implementation. Nazi propaganda has been illegal for over fifty years in Germany, and the government has, by and large, stopped there. It's not the beginning of a "slippery slope".
These kinds of restrictions were installed by the AMERICAN occupation government in order to get Germany AWAY from its Nazi past, they're just now being implemented for the Internet in the samy way that they have been implemented for the conventional press for over fifty years. Germans have just found this restriction to be quite sensible and have kept it.
In fact, Germans have freer speech than Americans in many ways. Please take off your starred and striped glasses and see the world as it really is. The USA is not any more a "bastion of freedom" than a large number of other countries, and it shows amazing amounts of hypocrisy to talk about freedom while having actively supported and funded many of the most opressive tyrannies during the last 100 years.
I suppose you got that "real history" from one of the sites whose DNS entries are being changed? Because it is total, utter bullshit. The murederous hatred for Jews is perfectly obvious in Hitler's writing years before he came into power. And the Nazi's "promotion" of science was a joke, they promoted only things that were either usable for the war effort or propaganda, or which one of the leaders had taken a facny to. In the latter two cases, the "science" was often a total joke (e.g. the "racial science"). And of course, some of the best scientists were disparaged or even killed because they were Jews.
Sure, that's the smart way, and that's what I'd do - for everybody (It's also how SuSE does it). I really don't see why PATH=/bin:/usr/bin (you would add /bin, yes?) should be the default. Admittedly, anyone using the command line preferrentially would probably know why and how to change PATH, but why not spare them the hassle?
No, never used a Mac. Do they actually do this when saving text as PLAIN TEXT? I doubt it, otherwise I don't think that character set would be called "Windows-"
Or could it be that other plants could do the same job, but also have the same problem and are thus not considered? It doesn't work, so who gives a fuck why one of them is also not considered for other reasons? I mean, being against overzealous drug legislation is one thing, but portraying hemp as a solution to all our problems is just as dumb.
Putting some of the largest applications (such as KDE) into separate trees certainly makes sense, but I (and many others) prefer to lauch graphical apps from the command line, so not having them in the PATH is completely unacceptable.
Sounds different to "Put everything in separate folders, then link what you need, which is what I was arguing against. And sounds like an awful lot of work for the benefit of "clean" disks (for a highly arguable definition of "clean").
Because I know the exact source of the problem: Microsoft decided that right and left double quotes must look different (which is not so bad an idea) and wrote their programs to use a proprietary, non-standard extension of the ASCII characters in order to preserve this difference when operating on plain text (which is). While they were at it, they included the apostrophe and a few other characters.
Additional questionoid: how much of the surface of the earth would need ot be converted to hemp to actually take care of '99% of our energy needs'? Where would we plant food?
No, the symlink requires one extra disk seek, possibly two if the link text is too large to fit into the link's inode. And absolute paths won't help at all, not if you insist on symlinking everything.
Think disk seeks, please. Scanning 20 small directories takes almost 20 times as long as scanning one large one. And it's a matter of several million CPU cycles.
Um, the point of chroot is that you have ONE 'fake' root, and the chrooted program can't access anything outside. So do you want the program to be chrooted into its own directory and unable to write any user-specific data, or chrooted to the user's directory, requiring the ENTIRE system to be hardlinked there? Or am I misunderstanding something?
Imagine the above, 5 times a day, in greatly varying shades of cluefulness and politeness...
Sorry, but disk seeks take time in the millisecond range, and it's not something that has gotten much faster with recent disks. And it's NOT only one disk seek when you add in shared libraries, configuration and data files, and possibly access to other applications with which the program interfaces. For a large application, it could make the difference between a startup time of 5 seconds and 10 seconds, which is quite a lot.
The cache doesn't work for negative results (i.e. typos), except when you make it so that a new executable won't be found until you tell the shell to rebuild the cache, in which case it will THEN do an exhaustive scan. Not as bit a performance problem, but a pretty braindead design. How often do you want to tell a newbie why the shell can't find his new shell script?
That's because Mozilla apparently contains a bugfix for Mocrosoft's non-standard ASCII extension. Netscape 4.7 doesn't, and I'm afraid the Sparc version of Mozilla is too damn bloeated to use. Besides, it's no excuse for using a broken charset that some browsers will fix it.
Doesn't happen. We're talking about HUGE systems that are custom built for each customer and need constant modification adn extension, over decades. Open-sourcing the components from which they are built makes very little difference, as much more work and money goes into the building process, which is different for each customer.
Dunno the details, but that works only for positive results, not negative ones, right? So each typo still causes an exhaustive search. That, or you'd have to tell the shell explicitly to do it after adding a new executable.
No, and it wouldn't help, because it would still force the system to go through ALL those directories to find an executable in some cases (especially for a typo). In fact, it would be much, MUCH worse than hundreds of entries in PATH, because it would cause a lot of directories to be scanned that don't even contain binaries at all.
Sure, and we'd never want a program to be able to write, say, a date or configuration file to a user's home directory...
Which anybody not using Windows can tell from the fact that your apostrophes appear as question marks due to Microsoft not using ASCII. Please fix...
Dunno about you, but I hardly ever launch programs through menus and never through desktop icons. If you work at the command line most of the time because of its greater flexibility, having to grab the mouse and wading through a menu or minimizing all the windows in front of a desktop icon just to start a program is actually much SLOWER than typing in the name.
Um... You still want to RUN those applications, yes? And you don't want to remember and type in the full path for 2000 executables, yes? So you want your shell to find the executables for you. Which is what the PATH variable is for.
Um... have you read the article? That's exactly the claim the author makes, and it's not even exaggerated much. At my university's system, /usr/local/dist/bin contains 1476 files. Even if each application accounts for several of them, that still means a few hundred applications, and a few hundred PATH entries would KILL the system, because each of these directories would have to be scanned to find an executable, which is a few dozen times slower than scanning only a few large directories.