FC2 went "gold" with a version of the kernel with the memory manager not tuned well for laptops. If you updated to the latest kernel package post-install, the issue would have been resolved. Another quick fix was to reduce the size of your swap file/partition.
XLibs and X are two seperate things. Check the package selections in your install options carefully. Yes, you need Xlibs because you need java to do anything with Oracle and the Oracle installer, and that is a given. So you access the server (running without X) remotely using ssh -X or some other method and fire up the installer and it uses your local workstation's X server as God intended.
While cooler, "real explosions" with interesting shockwaves are extremely dangerous. Gasoline and detcord are safer, known quantites that stuntmen and techs know how to work around. Film at the right speed, add some black powder charges to send debris flying, it'll look like what movie-goers expect without being deadly to those involved in the already expensive process of production.
1) Amiga didn't have a unified memory space with NUMA cache-coherency between all participating chips 2) Amiga had multiple processors, but they were all Commodore parts, and soldered in. We're talking about bus standards, and ISAs, and your choice of vendors and upgradability and all that stuff which is more difficult to spec-out AND get buy-in for. It's not a vendor stovepipe.
Hell, a friggin SNES has 4 coprocessors, a TurboGFX 16 had like 6, but you don't see people comparing THAT to PCs or Amigas or anything else.
Amigas weren't the only ones. Have you ever looked at an SGI workstation from the same era? Same kind of architecture, only more flexible.
PC architectures post-ISA were already surpassing the Amiga in potential. Bus interconnects, add-on cards, all that stuff was there. The software wasn't all there if you were using Microsoft though (one dynamite one was BeOS, but no one remembers that).
I don't know. You Amiga fanboys don't even know the significance of your own system in the grand scheme of 80s and 90s computing technology. You have tunnel vision. It was important for commercial reasons, like the Commodore 64. But it wasn't technologically groundbreaking nor unique, nor better or worse than any other architecture.
/sbin really did mean static-bin. There was also a convention for/stand to contain standalone binaries that could be used if the C-library was hosed. Nowadays you just look for commonly-used commands that start with 's' in/bin or/sbin, i.e. sln for statically-linked ln.
Binaries for doing things on the system that weren't built into the shell usually lived in your home directory, and your home directory was all of, or at the beginning of your path. Binaries that everyone could use would be owned by the 'bin' account and lived in/usr/bin. But eventually user directories moved out of/usr to/home as the size of the system software grew to the point where it was relocated to/usr/bin +/usr/lib, effectively.
It may mean that now (and/usr = Unix System Resources, yeah right)
But if you remember, programs like mount and user databases (when passwd files got too long to scan) were thrown into/etc. And configuration files also used to live in places like the root directory, or/var./usr or even/lib, sometimes in./conf/ subdirs.
So it really did mean etcetra. And/usr really did mean 'users', as in, resources for users not administrators. Well at one point it also held home directories before that was split off into home.
This makes Solaris PAM compatible with Linux/BSD-style MD5 shadow hashes distributed via file, NIS, LDAP, or whatever. It will process an arbitrarily long password.
And in that case, you should edit your/etc/ssh/sshd_config and set PAMAuthenticationViaKBDInt to yes. That way you can manage your auth/session modules via pam.conf and manage your security policy in one place.
You don't need greater than 32-bit precision for any of the MAC ops. Usually that kind of limitation can be overcome by rethinking the algorithm, and doing some accumulation or error analysis outside of the GPU.
Give me a fucking break. The proposed law has a gigantic list of exceptions that are very broad: the only target is residential room lighting. And that proposal is state-of-energy-hungry California specific, and it merely adds sin taxes to incandescents for room use.
Big fucking deal. It amounts to big swinging dick, but looks nice on a voting record. And it'll probably get the CFLs out in the open and noticed.
Sorry to discontstruct your predictions for a liberal Madison Avenue / Hollywood joint conspiracy.
Unix sockets are excellent inter-process sync primitives. Coupled with the poll()/select() idiom you can create mailboxes for processes to send messages to each other, and depending on the OS implementation, you may get it with zero copies (or at most one), which is great.
You can use this in conjunction with shared memory when you don't want any copies to occur, or when you want to implement many-reader, single-writer.
And if that's not enough there's explicit POSIX IPC; not the greatest APIs but consistent in behavior across platforms. I mean it's good enough for Oracle...
If you don't touch the heap, then not much is gained from pthreads over fork() in terms of memory usage. Code segments are shared, data is copy on write, and the stack is not shared in either case.
Create your thread pool, have it wait for events on a queue, pull off and process, loop. If handled_requests > threshold, optionally kill + restart thread. (Implementation of that last bit left as user excercise)
ECMA is not a very widespread organization that puts its name on internet-related technologes, unlike ISO, IEC, or W3C. It used to mean, at one point, the European Computer Manufacturers' Association, but now it's no longer an acronym, and the Ecma group serves primarily as a steering comittee for IEC.
The only thing we deal with on a day-to-day basis in IT that has its name on it is ECMAScript. They took JScript, Javascript, put it together in one spec, and fast-tracked it to being approved as ISO/IEC 16262. That is the group's claim to fame, so why not name it after it? After all, the ORGANIZATION ITSELF chose the name, so if they wanted to have two scripting languages, well they're out of luck.
I suppose if you have to standardize any scripting language, ISO/IEC 16262 is as good as any.
You know why it was called that? Because Netscape thought Java was going to be the future. JavaScript was a way to glue HTML page elements (forms, mouse clicks, page loads, images, links) to an embedded java applet in the page that would do the "heavy lifting" or allow you to control the java applet using native-looking controls couched in action-less forms. And LiveConnect was the magic glue that made it possible. JavaScript used to be called "LiveScript" for just that reason.
And now we have this crazy confusion about JavaScript Java, when they now have little to do with each other.
Let's just call it ECMAScript so no one gets confused.
The only solution that will be accepted by the MPEG license patent holders (a very large portfolio of companies that would have to be negotiated with individually) is Red Hat footing the bill for each downloaded copy. That will never happen.
If Red Hat did say "Screw it" and shipped FFPMEG anyway with the "risky" codecs enabled, it would make them a target for lawsuits, as they are, as you say, the "Biggest Free Software company, and the richest Free Software company." That makes them the biggest target. Smaller distributions with little or no financial resources can take the risk for delivering a complete distro witih legally questionable components. They don't attract much attention, and exist to serve the end user.
Red Hat is too big to do something like that. Of course, they don't go out of their way to make it difficult to retrofit your installation to patch the holes. That's what the FreshRPMS repository is for.
that won't mean anything, or change anything from a user's perspective. It won't fix your problem when you can't figure out how to install firefox.2.0-fc7.i386.rpm on your x86_64 FC4 box.
It may be important to sysadmins, and definitely developers who package for Fedora, however.
One good thing that could come out of it is revising the multi-file, single-thread-locked Berkeley DB backend. Maybe SQLite? That'd be nice. That way you can have multiple processes doing transactions against the configuration database. And you could support PIT backups and restores of all managed packages and stuff... *drool*
Packaging mistakes bite every distribution (Gentoo, Kubuntu, you name it)
The error left him in a touch spot. Rather than trying a different tact, he did a potentially damaging operation and got burned. He didn't even take steps to fix the problem.
So his "solution" is to trash his system and move to another.
Complaints about Fedora's packaging infrastructure have some merit. But he is ignoring the efforts that the community is undertaking to resolve many issues (from the 2nd-party repository merge, to the extras management changes and integration, to little things, like the "where's my MP3 codec" user warning and autodownloader for FC7)
So, naturally the first reaction by those who are more intimately knowledgable about distributions and their pros/cons is to say: "He's just being ESR".
Because we don't want people point to his tirade to bolster a position on a technology that is little more than a religious argument or dick-measuring-contest. It was a passionate statement by a party with non-neutral interests who is becoming increasingly marginalized, and thus should be taken with a very large grain of salt.
Frankly I'm tired of Gentoo vs. Ubuntu vs. Fedora rants and switching stories. Why do we need to throw more fuel on the fire?
We need to focus on common standards and distribution specific strengths.
I use Windows and all manner of Unix at home and work, and I have not been motivated to move to FF2 on any of the systems. There really isn't anything new under the sun, and it doesn't improve memory leaks, so I stick with 1.5.0.9 and every OS is at the same version, so profiles are compatible across environments...
So, the idea of an operating system that you can just copy and give to a coworker or install on server-I-pulled-from-the-garbage without a license doesn't appeal to you anymore?
Well I have the linux for you! Single CD with every legally questionable bit of software on there that does everything your heart desires. I call it "LaLaLand Linux"
Hey, NVidia just slapped me with a cease-and-desist for distributing their intellectual property on these boot ISOs, sorry, no more updates for you.
speaks to yours (and much of the linux community's) vast ignorance of the "multimedia codecs problem".
No amount of money or engineering time will fix the problem.
The issue is that Red Hat does not own the patents on the technologies used by any of the popular multimedia codecs. Licesning groups like MPEG want significant royalties per seat.
You pay for bundled codecs with Windows XP in the sticker price.
FFMPEG and the players that use it together form an extremely capable drop-in replacement for (QuickTime + RealPlayer + WMP), built from reverse engineered source code, that plays nearly every file format you can think of out-of-the-box.
But Red Hat could never ship that in source code form, or make it free for download in binary form.
Neither does Ubuntu. Linspire allows you to get it, but Linspire has a pay-to-download service that they use to cover their own asses and extract money from you, to turn over to royalty-demanding groups.
So there's the situation in a nutshell. Legal, not technical.
It just encourages people to post something, anything, even if they don't particularly have anything to contribute beyond the review, just to put that referral link in context and hopefully get some buy-throughs.
It's not a reflection on you, but it's a general trend. Slashdotters are smart enough to "know the difference"; in that if you _REALLY_ wanted to comment on the book, having bought it, and encouraging others to buy it, then you'd put a non-referral link. That speaks to slashdotters who know you have nothing to gain, and in considering your opinion understand there is a concious effort to remove bias from your remarks.
Slashdot Mirror
FC2 went "gold" with a version of the kernel with the memory manager not tuned well for laptops. If you updated to the latest kernel package post-install, the issue would have been resolved. Another quick fix was to reduce the size of your swap file/partition.
XLibs and X are two seperate things. Check the package selections in your install options carefully.
Yes, you need Xlibs because you need java to do anything with Oracle and the Oracle installer, and that is a given. So you access the server (running without X) remotely using ssh -X or some other method and fire up the installer and it uses your local workstation's X server as God intended.
THE END
While cooler, "real explosions" with interesting shockwaves are extremely dangerous.
Gasoline and detcord are safer, known quantites that stuntmen and techs know how to work around. Film at the right speed, add some black powder charges to send debris flying, it'll look like what movie-goers expect without being deadly to those involved in the already expensive process of production.
Us Fedora users are still here. :-D
LEGION AARRRRRGHHHH
1) Amiga didn't have a unified memory space with NUMA cache-coherency between all participating chips
2) Amiga had multiple processors, but they were all Commodore parts, and soldered in. We're talking about bus standards, and ISAs, and your choice of vendors and upgradability and all that stuff which is more difficult to spec-out AND get buy-in for. It's not a vendor stovepipe.
Hell, a friggin SNES has 4 coprocessors, a TurboGFX 16 had like 6, but you don't see people comparing THAT to PCs or Amigas or anything else.
Amigas weren't the only ones. Have you ever looked at an SGI workstation from the same era? Same kind of architecture, only more flexible.
PC architectures post-ISA were already surpassing the Amiga in potential. Bus interconnects, add-on cards, all that stuff was there. The software wasn't all there if you were using Microsoft though (one dynamite one was BeOS, but no one remembers that).
I don't know. You Amiga fanboys don't even know the significance of your own system in the grand scheme of 80s and 90s computing technology. You have tunnel vision.
It was important for commercial reasons, like the Commodore 64. But it wasn't technologically groundbreaking nor unique, nor better or worse than any other architecture.
*shakes head*
/sbin really did mean static-bin. There was also a convention for /stand to contain standalone binaries that could be used if the C-library was hosed. /bin or /sbin, i.e. sln for statically-linked ln.
Nowadays you just look for commonly-used commands that start with 's' in
Binaries for doing things on the system that weren't built into the shell usually lived in your home directory, and your home directory was all of, or at the beginning of your path. /usr/bin. But eventually user directories moved out of /usr to /home as the size of the system software grew to the point where it was relocated to /usr/bin + /usr/lib, effectively.
Binaries that everyone could use would be owned by the 'bin' account and lived in
It may mean that now (and /usr = Unix System Resources, yeah right)
/etc. And configuration files also used to live in places like the root directory, or /var. /usr or even /lib, sometimes in ./conf/ subdirs.
/usr really did mean 'users', as in, resources for users not administrators. Well at one point it also held home directories before that was split off into home.
But if you remember, programs like mount and user databases (when passwd files got too long to scan) were thrown into
So it really did mean etcetra. And
man crypt_bsdmd5
/etc/security/crypt.conf:
/etc/ssh/sshd_config and set PAMAuthenticationViaKBDInt to yes. That way you can manage your auth/session modules via pam.conf and manage your security policy in one place.
in
CRYPT_DEFAULT=__unix__ => CRYPT_DEFAULT=1
This makes Solaris PAM compatible with Linux/BSD-style MD5 shadow hashes distributed via file, NIS, LDAP, or whatever. It will process an arbitrarily long password.
And in that case, you should edit your
You don't need greater than 32-bit precision for any of the MAC ops. Usually that kind of limitation can be overcome by rethinking the algorithm, and doing some accumulation or error analysis outside of the GPU.
DOS ID107 DEMS GONNA STEEL MA INCANDESENCES
Give me a fucking break. The proposed law has a gigantic list of exceptions that are very broad: the only target is residential room lighting. And that proposal is state-of-energy-hungry California specific, and it merely adds sin taxes to incandescents for room use.
Big fucking deal. It amounts to big swinging dick, but looks nice on a voting record. And it'll probably get the CFLs out in the open and noticed.
Sorry to discontstruct your predictions for a liberal Madison Avenue / Hollywood joint conspiracy.
Unix sockets are excellent inter-process sync primitives. Coupled with the poll()/select() idiom you can create mailboxes for processes to send messages to each other, and depending on the OS implementation, you may get it with zero copies (or at most one), which is great.
You can use this in conjunction with shared memory when you don't want any copies to occur, or when you want to implement many-reader, single-writer.
And if that's not enough there's explicit POSIX IPC; not the greatest APIs but consistent in behavior across platforms. I mean it's good enough for Oracle...
If you don't touch the heap, then not much is gained from pthreads over fork() in terms of memory usage. Code segments are shared, data is copy on write, and the stack is not shared in either case.
http://users.actcom.co.il/~choo/lupg/tutorials/mul ti-thread/thread-pool-server.c
Create your thread pool, have it wait for events on a queue, pull off and process, loop. If handled_requests > threshold, optionally kill + restart thread. (Implementation of that last bit left as user excercise)
ECMA is not a very widespread organization that puts its name on internet-related technologes, unlike ISO, IEC, or W3C. It used to mean, at one point, the European Computer Manufacturers' Association, but now it's no longer an acronym, and the Ecma group serves primarily as a steering comittee for IEC.
The only thing we deal with on a day-to-day basis in IT that has its name on it is ECMAScript. They took JScript, Javascript, put it together in one spec, and fast-tracked it to being approved as ISO/IEC 16262. That is the group's claim to fame, so why not name it after it? After all, the ORGANIZATION ITSELF chose the name, so if they wanted to have two scripting languages, well they're out of luck.
I suppose if you have to standardize any scripting language, ISO/IEC 16262 is as good as any.
You know why it was called that? Because Netscape thought Java was going to be the future. JavaScript was a way to glue HTML page elements (forms, mouse clicks, page loads, images, links) to an embedded java applet in the page that would do the "heavy lifting" or allow you to control the java applet using native-looking controls couched in action-less forms. And LiveConnect was the magic glue that made it possible. JavaScript used to be called "LiveScript" for just that reason.
And now we have this crazy confusion about JavaScript Java, when they now have little to do with each other.
Let's just call it ECMAScript so no one gets confused.
The only solution that will be accepted by the MPEG license patent holders (a very large portfolio of companies that would have to be negotiated with individually) is Red Hat footing the bill for each downloaded copy. That will never happen.
If Red Hat did say "Screw it" and shipped FFPMEG anyway with the "risky" codecs enabled, it would make them a target for lawsuits, as they are, as you say, the "Biggest Free Software company, and the richest Free Software company." That makes them the biggest target.
Smaller distributions with little or no financial resources can take the risk for delivering a complete distro witih legally questionable components. They don't attract much attention, and exist to serve the end user.
Red Hat is too big to do something like that. Of course, they don't go out of their way to make it difficult to retrofit your installation to patch the holes. That's what the FreshRPMS repository is for.
that won't mean anything, or change anything from a user's perspective. It won't fix your problem when you can't figure out how to install firefox.2.0-fc7.i386.rpm on your x86_64 FC4 box.
It may be important to sysadmins, and definitely developers who package for Fedora, however.
One good thing that could come out of it is revising the multi-file, single-thread-locked Berkeley DB backend. Maybe SQLite? That'd be nice. That way you can have multiple processes doing transactions against the configuration database. And you could support PIT backups and restores of all managed packages and stuff... *drool*
One can dream.
ESR is making a mountain out of a molehill.
Packaging mistakes bite every distribution (Gentoo, Kubuntu, you name it)
The error left him in a touch spot. Rather than trying a different tact, he did a potentially damaging operation and got burned. He didn't even take steps to fix the problem.
So his "solution" is to trash his system and move to another.
Complaints about Fedora's packaging infrastructure have some merit. But he is ignoring the efforts that the community is undertaking to resolve many issues (from the 2nd-party repository merge, to the extras management changes and integration, to little things, like the "where's my MP3 codec" user warning and autodownloader for FC7)
So, naturally the first reaction by those who are more intimately knowledgable about distributions and their pros/cons is to say: "He's just being ESR".
Because we don't want people point to his tirade to bolster a position on a technology that is little more than a religious argument or dick-measuring-contest. It was a passionate statement by a party with non-neutral interests who is becoming increasingly marginalized, and thus should be taken with a very large grain of salt.
Frankly I'm tired of Gentoo vs. Ubuntu vs. Fedora rants and switching stories. Why do we need to throw more fuel on the fire?
We need to focus on common standards and distribution specific strengths.
I use Windows and all manner of Unix at home and work, and I have not been motivated to move to FF2 on any of the systems. There really isn't anything new under the sun, and it doesn't improve memory leaks, so I stick with 1.5.0.9 and every OS is at the same version, so profiles are compatible across environments...
So, the idea of an operating system that you can just copy and give to a coworker or install on server-I-pulled-from-the-garbage without a license doesn't appeal to you anymore?
Well I have the linux for you! Single CD with every legally questionable bit of software on there that does everything your heart desires. I call it "LaLaLand Linux"
Hey, NVidia just slapped me with a cease-and-desist for distributing their intellectual property on these boot ISOs, sorry, no more updates for you.
You got old and tired of hacking it; now you have the money to spend on hardware you pick from HCLs.
speaks to yours (and much of the linux community's) vast ignorance of the "multimedia codecs problem".
No amount of money or engineering time will fix the problem.
The issue is that Red Hat does not own the patents on the technologies used by any of the popular multimedia codecs. Licesning groups like MPEG want significant royalties per seat.
You pay for bundled codecs with Windows XP in the sticker price.
FFMPEG and the players that use it together form an extremely capable drop-in replacement for (QuickTime + RealPlayer + WMP), built from reverse engineered source code, that plays nearly every file format you can think of out-of-the-box.
But Red Hat could never ship that in source code form, or make it free for download in binary form.
Neither does Ubuntu. Linspire allows you to get it, but Linspire has a pay-to-download service that they use to cover their own asses and extract money from you, to turn over to royalty-demanding groups.
So there's the situation in a nutshell. Legal, not technical.
Ruby is the next perl. It is now what Perl 6 cannot be.
Soon, it will be just as fast.
It just encourages people to post something, anything, even if they don't particularly have anything to contribute beyond the review, just to put that referral link in context and hopefully get some buy-throughs.
It's not a reflection on you, but it's a general trend. Slashdotters are smart enough to "know the difference"; in that if you _REALLY_ wanted to comment on the book, having bought it, and encouraging others to buy it, then you'd put a non-referral link. That speaks to slashdotters who know you have nothing to gain, and in considering your opinion understand there is a concious effort to remove bias from your remarks.