I did cite real world examples. You took the "how should I know" (with hand waving) approach. I thought perhaps you were being unreasonable due to your unfamiliarity with the particular hardware configuration that I have.
Now I know you're being unreasonable because you're bored, irritable, and I'm the only one feeding you.
----- You're still wrong. If compiling software for the same architecture gives different results on different hardware, then something is terribly wrong. You can't argue that ----- I guess we need to define "architecture" and "hardware".
Architecture is what you'll find in the kernel source tree. arm, i386, m68k, Sun, HPPA, etc. Hardware is what you'll find in kernel modules. Chipset patches, ide bus patches, pci bus patches, etc.
Consider the following situation: System A is used to produce generic package binaries for distribution. System B and C have the same architecture but different hardware. Package 1, 2, and 3 are installed on both systems. Package 3 uses libraries included from 2 and Package 2 uses libraries included from Package 1. Developer's lists are full of occurences where upgrading Package 2 on both systems has resulted in Package 3 no longer functioning properly on System B yet still functioning properly on System C. It happens and it drives the package maintainers crazy when they need to go digging through the Makefiles of package 2 and find nothing wrong. Then they start checking the Makefile for Package 1 and find out that some obscure argument has far-reaching consequences.
----- These differences are touched by on 5% of the code in the world ----- That would be the 5% of the code that causes headaches for 95% of the programmers. That would be the 5% of the code that requires building from source over prepackaged binaries.
Optimization isn't about squeezing out the last 0.1% of performance. This is about program stability. It takes only one bad instruction in over a billion assembler commands to cause "Abnormal exit" "Program Terminated" or "Segmentation fault".
I'm not trying to pull you away from binary packages. You were pretty hot about saying that there's no additional performance or stability in building from source. That bug that's in 5% of the code says you're wrong.
----- Start with like the postfix pacakges, and see how they offer options (even mutually exclusive ones), without requring a user to take the kitchen sink. ----- All done in.conf files after compilation and just as easy to do with source packages. If you're paranoid about --enable-with options you're better off building from source so that you know which --enable-with options might be an issue.
----- For all I know your RAM is failing ----- Or you just don't know. Using binary packages isn't going to help you know anything more.
----- for all I know you build the program wrong. ----- Or you just don't know. I use the same./configure options to build MPlayer every time. On Debian it will occaisionally segfault. On LFS it doesn't. The problem may be in libdvdread. That's more reason to build those from source rather than use prepackaged binaries.
----- How stupid can you possibly be? ----- The existence of idiosyncracies between binaries compiled for my architecture and packages compiled on my machine does not make me stupid.
----- This is all a configuration management issues ----- The binary package maintainers can't produce Makefiles that work for the majority of a target audience AND account for each individual user's specific hardware configuration. Except for select kernel packages (which are necessary) the "one-size-fits-all" approach will always result in a few problems.
----- If I compile the exact code on two different sets of hardware, but using the exact same software, I'd had better damn well come out with the same generated code, ----- If you compile source for i386 and the same source for m68k using gcc-3.3.1 linked to glibc-2.3.2 on both machines running the 2.4.24 kernel I hope you don't come up with the same generated code. The difference is more subtle for Pentium vs. AMD but it still exists. The difference is even more subtle for the same processor with different chipsets but still exists. The difference may still exist with the same processor and chipset using different BIOS revisions.
----- or I have a bug in my hardware, or potentially my toolchain ----- VIA doesn't consider the ide-scsi emulation in their chipset to be a bug but it sure wreaks havoc with UDMA. I haven't seen this become a big problem under Linux but Win2k sure took a long time to install using INT13h calls to the hard drive.
----- I cited a specific example, Debian ----- What option would you enable in building from source that Debian doesn't enable? You're mudge with source installation was needing to recompile to remove something that you don't want. AFAIK, Debian packages (and most RPMSs) are typically built with just about everything. If you don't want an option you'll still need to recompile.
----- Could be any number of things ----- You're pontificating. I'll post it in my journal when Firefox starts just fine after I build it from source.
----- Everything is always compiled form source, just not necessarily by you. I'd love to see you expand on this in an attempt to explain how you compiling everything from source guarantees more stability ----- The stability guarantee is increased by the hardware matching if _every_ library on the system has been built from source. If someone else compiled it they may have been using a different glibc or a different kernel. Case in point: there is no package for the Atheros drivers or the ndiswrapper for Centrino. I have to build those myself. The Atheros drivers (built by me) cause my Debian kernel (built by them), to upchuck on occasion. Another case in point: In Deb 3.0, kernel 2.4.21, with Xf86 4.2.0 the stock radeon drivers would cause Xf86 to lock the system when starting in 1600x1200. All other screen modes worked fine. Compiling the kernel's radeon.o and Xf86's radeon.o from gatos or dri fixed this problem. Another case in point: There is no.deb for mplayer (at least not from Debian). If I built MPlayer from source on my Debian system it would still segfault when playing my DVDs on occaision. MPlayer will loop through Ghost in the Shell all night long on my LFS.
Perfect examples illustrating situations where sometimes it's not just the app, sometimes it's not just the driver, sometimes it's not just the compiler... Sometimes it's just that the whole thing needs to be in proper alignment to get flawless stability.
----- How much time are you wasting trying to eak out a 5% performance increase? ----- That 5% performance increase means I don't have to spend $120 for a DVD player that won't be outdated by the next iteration of DVD+.
Of course, since the Radeon7500 is such a |expletive-deleted| of a video card, it also means that I still watch my DVDs on my 19" monitor when that S-video cable could very easily reach my TV. Some day _someone_ will figure out what the radeon driver does to mangle timings sent to the TV-out port. The VESA driver has no timing problems but lacks the performance needed for DVD.
----- Building from source makes changing options more different. If you later decide you don't want support for a certain feature in a program, you have to recompile it and everything that depends on it. In a binary-package situation, you just download the packages and reinstall ----- Oh yeah? And what do you do if the binary package includes a certain feature that you decide that you don't want?
Most binary packages are compiled with all available options for precisely the opposite reason that you give.
----- There are no 'magic' or special optimizations to gain from compiling with custom optimizations. gcc -O2 gives 99% of the speed you will get. ----- You're right. Mostly. But tell me why Firefox 0.8 refuses to start on my K6-3 400 when it runs happily on my P2 400? Additionally I bet that Firefox 0.8 will run just fine once I build it from source. There is no magic in building single packages from source but if _everything_ is built from source there's a better guarantee on things working.
----- it took him, on a very modern machine just a year ago, nearly 3 days to have a full working system with X etc ----- Bah! He's an amateur. I build fully functional systems completely from source in less than 24 hours of compiling time on 400 MHz machines.
That said, unless you're a hobbyist or using really old machines, there's no real need to build from source. In the case of really old machines you have to decide if the extra time at the front-end of building from source is worth the little bit of performance.
In the case of a K6-3 400 MHz machine with UDMA 33 and a VIA Apollo MVP3 chipset the answer is: YES! Building from source let's me watch Fellowship of the Ring without having to buy an external DVD player. Debian yielded choppy playback.
Oh stop already. Unless you're building _every_ library from source then the optimization of later libraries is lost on the precompiled libraries they're dependent on.
It's a nifty feature of Gentoo but how many users really want to wait for glibc? If they don't wait for glibc then are they really gaining anything significant when they build Mozilla manually as opposed to using a nightly build?
Think Tetris. If you don't optimize from the very first row then optimization at row 15 isn't going to save your backside.
Rebuilding selected packages from source in Gentoo is little more than an advertising gimmick. Unless the entire system is built from source the low-level optimizations may actually work against each other.
There is no real "combining the best of both worlds" unless you mean you can use supplied packages and source tarballs for things that don't have packages.
All that aside, though, I like the look and feel of Gentoo and think it'd be a good candidate for the above-average user who's new to Linux.
I think RedHat was working on an.iso for EIBB-Linux until they prematurely moved to the Make Money stage.
Yes, we do agree. I would like to see every home computer running Linux. I guess I'm backtracking on the arguments of why Linux is better, though. When EIBB-Linux reigns the world, how many easily exploitable security flaws will be found in default installations of iptables rules? EIBB-Linux isn't going to attract the real netfilter gurus. While in the past the permissions structure of *nix made this a fairly paltry consideration it's currently being circumvented by beasts like Mozilla. How long before someone figures out how to load the cache with precompiled.so files masquerading as something else and figures out a way to get Java or Flashplayer to #include them? How long before users go around making everything suid root just because that's the easiest hint to solve their problem that they get from coworkers?
I think the best reason for a difficult install is that it can eventually lead the user to recognize the importance of./configure and make as a normal user, but why make install needs to be root.
Once Linux becomes the desktop standard I can envision the following coversations:
Clueless Coworker #1: "I was using my EIBB system last night and and and weren't working correctly. I kept getting errors about and and " Even More Clueless Coworker #2: "Oh. Just login as "root" and do everything from there. It'll solve that." CC #1: "But I heard that using root was bad?" EMCC #2: "That's only what those people using that _hacker_ linux say. The other way you can do it is by just logging in as root and typing chmod u+s since everything's installed by root anyways. Then you won't actually have to be root." CC #1: "Ohhhhhhh... Okay."
And then people will wonder why spam and zombie boxes still exist. They'll say it's all because of people using that _hacker_ linux. And soon that _hacker_ linux will be illegal. I've heard about it in some dorms at liberal arts colleges a few years ago. The dorm RAs and SAs would issue warnings to students caught using Linux because only someone who wants to do something illegal would use anything but Windows.
----- So...have they come to get you yet? No? No witch hunt because you are a Pagan running Linux on a Sparc? Hmmm...that's odd ----- Did you run with an argument by answering your own question? Yes. Yes you did.
The correct answer was "yes". Now your response will be "You must be paranoid."
Linux may win the desktop war but, unless it remains difficult to install, BigBrotherLinux will end up with all the same problems of Windows. I wouldn't mind developing the next OS but rewriting all of my install scripts is sure going to be a PITA and I really don't want to go through the bleeding edge witch hunt again. I'm on the bleeding edge. Why can't the water-cooler gossips just deal with it?
They can dish it out but they can't take it. That's why they want easy-install Linux. They dished it out for years based on Microsoft superiority. Now that the superior MS bubble has finally started to crack they want BigBrotherEasyInstall-Linux so that they won't feel deficient anymore.
----- Corporate advertisers are the customers, and they pay big bucks for your eyeballs. ----- Flashback to the Neuromancer video game. Lungs and eyes paid best when you needed cash.
----- After the demise of X-Files ----- Interesting point.
I agree that there isn't much to appeal to males in my age category on TV anymore. If we accept the X-Files as being dominantly representative of programming which appeals to young males we can draw conclusions about society.
The X-Files was a show that fed paranoia. Micromanaging causes paranoia. Did the X-Files appeal to young men because we're being micromanaged by old men with Viagra dependencies?
----- This was the initial install. The kernel should have been built to suit the needs of the hardware in the laptop ----- Most distros don't autodetect hardware and build a custom kernel for it. They use a precompiled kernel and, if they're good, they may autodetect modules to be loaded. Even so, the Debian kernels tend to be several hundred k larger than any custom kernel that I've built myself. As time goes on and hardware keeps -marching forward this will become a larger and larger problem. In order to be compatible with a broad range of hardware out of the box optimization flags will be left out and extra compatibilities will be built in.
I don't see a problem for the average user, though. The average user isn't going to notice the extra 200k in their kernel or the missing -march=k6 in qiv. Think about it within the context of an evolving society, however. BigBrotherLinux will become popular simply because it suits the needs of the largest segment of the population. Suitability leads to subsidy. Humans, as a species, are suspicious of anything that they don't directly associate with. Suspicion leads to witch hunts. Witch hunts lead to laws. Most often these laws don't correct the witch hunt but seek to outlaw the target. The prevailing message is,"Don't be different or we'll come to get you, too." That's a bit dysfunctional for a society that purports to be diverse. It also suppresses progressive development.
While everyone will be subsidizing BigBrotherLinux through public service contracts (eg. installed at schools, on government infrastructures, in corporate environments) there will be little room left, and additional questioning, for anyone who wants to use something else. The system will be much the same as the ostracization we endured during the HUGE Microsoft boom throughout the 90s. Anyone who wasn't a complete Microsoft advocate was targeted for secret smiles and smirks by the water-cooler gossips.
In a nutshell I advocate Linux being difficult to install. The only driving force behind development and improvement is to demonstrate the existence of a better approach. When the water-cooler gossips are perfect just because they use "Linux" then there will be no better approach than "BigBrotherLinux". When BigBrotherLinux begins to stagnate and bloat there will be no compelling argument against it--unless BSD is still around.
----- config files to change the "r128" to "vesa". ----- You're right. You shouldn't have to do that. You probably shouldn't do it at all. Using the VESA driver negates just about every performance optimization that you had.
I see that there's a benefit to Linux not being easy to install. When Linux becomes easy to install then it will be just like Windows. The kernel will be generic (and huge) to account for all possible chipsets and drivers. Only one application will be installed for a given task. If people want to learn about their computer, how it works, and be able to use it properly then it's almost necessary for the system to be difficult. Eg. "Lemme think, learn how to debug pango, fontconfig, xft, glib, gtk, imlib, expat, qiv or go browse the web?" Which would most users choose.
I don't really have a problem with people installing Linux just as an average user and getting an easy install. What I worry about is that, due to the top-down corporate Big Brother iron fist that rules our society, when BigBrotherEasyInstallLinux becomes the popularly accepted (and funded through lucrative and huge government partnerships), will Debian be made illegal because it's different? If BBEI-Linux is easy to install, easy to use, and what the population is familiar with then the logical next question for the clueless majority is: "Why would anyone want to use Debian if it's difficult to install and maintain?" The logical next answer from the clueless majority is: *in low tones* "It's a _hacker_ distribution. They're doing things they shouldn't be doing."
So you see, once the population has EasyInstallBigBrother-Linux, water-cooler gossips come to claim Debian.
----- We then hit "generate" and it created a bunch of C code that went through gcc ----- This may be true but the code that it generated was most likely NOT the most optimized and streamlined C code for the task. Compiled code begins to break on different machines due to obscure hardware idiosyncracies even if it was compiled from the most correct and streamlined code. It'll break even more often if it's compiled from autogenerated material with extra fluff'n'stuff in it.
Your Telelogic SDL generated SIP client/server may have worked but I guarantee it would be a nightmare to write a fully-fledged corporate application that would run across a broad range of processors and chipsets within the company. I guess this explains why every VP on the planet wants Java webapps. Then they gripe about the slow performance of a 2.4 GHz chip.
----- a small central piece called the "kernel" and a larger piece that has the applications and drivers ----- I appreciate THG for putting the foot forward to try and introduce a large user base.
----- Programmers work out how to do things better, faster, and with less energy ----- I like programmers as much as the next nerd, but you're On Crack.
Programmers work out how to take shoddy databases and interface them with shoddy operating systems while presenting a bug-ridden interface to the user in a sub-optimal environment. Translation: They code VB to talk to SQL so that people can use Windows to send reports to management using Java plugins on MSIE.
I know that most programmers like to solve problems but they have to eat, too.
Let's try the devil's advocate approach: What if Bill was right? What conditions need to be met in order to make Bill right?
Let's tackle visual programming first:
The reason why visual programming isn't a plausible standard is because we don't have GCC and appropriate toolkit interfaces on hardware chips. In order to make Bill right the entire computing world would need to place not only the OS on a chip (Amiga) but would need to standardize and make chips for the compilers and visual interfaces (X, glib, gtk, tcl/tk, qt, etc.). Even that's only enough for basic user interface visual programming. I can't even imagine what toolkits are necessary for games programmers to do all of their models, raytracing, 3D effects and others.
Maybe if the PC architecture were adapted to allow hot pluggable chips. In order to be compatible, however, it would require frequent freezes of your favorite compiler and toolkits in order for them to be standardized. The system would have to slow down to allow for maximum distribution and population permeation. The last thing you want to do is visually design a software package based on your EEPROM of gcc-3.3.2, Xf86-4.4.40, glib-2.4.0, gtk-2.4.0 and find out that, because of a low-level logic problem in the realm of computer and electrical engineering the program segfaults on home computers using EEPROMs with gcc-3.3.1.
If everyone were using the exact same hardware built at the exact same factories then the platform would be stable enough to allow reliable visual programming on a grand scale. This sort of system would still not guarantee quality, efficient, streamlined, and secure code. This sort of system would guarantee nothing but functionality. Due to the presence of patent law and intellectual property which gave birth to the multitudes of "me-too" hardware and ".100% SoundBlaster compatible" hardware we'll simply never attain that level of platform stability.
That brings around the question of hardware: What would it take for Bill Gates to be right about the price of hardware becoming negligable? First we'd have to remove all of the patent laws and intellectual property regarding chip design and manufacturing. Intel probably won't go for this. It is possible to squeeze out all of the competition (I miss Motorola chips) but the industry is demonstrating that patent law and IP extends to the subcontractors in chip manufacturing as different cards, named the same, which come from different plant locations demonstrate obscure idiosyncracies.
In order for Bill to be right about hardware the world needs to move to a completely open and free model which would make him wrong about visual programming. In order for Bill to be right about visual programming the world would need to standardize on a frozen hardware platform encompassing over 150 source code trees.
There is a third way for Bill Gates to be right. If we could rework the conceptual design of a computer so that it doesn't function like a system of over a trillion light switches then we could create a fast, reliable, and secure hardware platform which doesn't rely on compiled source code to correctly flip the switches.
I know what I'm thinking about for the rest of the day: Holographic computing using preinitialized template holograms.
And why do I keep seeing all of these MS banner ads on/. which repeatedly try to tell me that MS implementation is cheaper, faster, and better?
If night school taught Linux maintenance there wouldn't be any additional intellectual cost to Linux startup and the long-term savings due to better coding, design, and implementation would add up quickly. MS only demonstrates the far reaching power of its megalopoly.
Say you irritate someone in a fairly elevated position and say that person is fairly well connected with someone who can add people to the terror list. So they add your name to the terror list.
So some FBI agent wants to know why you're on the terror list. He gives your name to the local PD as "just check on this guy". The local PD, being fairly bored with nothing better to do, happily and eagerly complies with the new system of checking on potential terrorists. You start to wonder why all of your friends leave the bar about 15 minutes after you show up. They say you're paranoid but everyone keeps looking over your shoulder. You start to get pulled over because your brake lights looked funny, or you were doing 65.2 mph in a 65 zone.
Your boss starts to take a lot more interest in your personal life and becomes offended when you don't open up your life to him. Other managers at work also begin poking and prodding your work. You start to challenge all the extra-special attentin and ask what the purpose of the seeming harassment is. Everyone's eyes glaze over and they accuse of you of being paranoid.
Eventually the FBI agent wears you down with all of this clandestine poking and prodding and investigating. Perhaps you even start to come apart at the seams. The intense scrutiny leaves your nerves on edge and your character becomes more antagonistic.
Where are the reparations? Where's the control on this system? At what point is the initial name-submitter responsible for starting a witch hunt?
Other than that consideration... fine, make your lists. Who gives a good cat's backside?
Back in their roots in the 1800s and early 1900s, Republicans WERE Libertarians. They strove to keep government small and out of the way. As the communists started kicking their butts in the polls. however, they had to adapt to appeal to the public opinion of the common half-butt-educated American know-nothing.
Slashdot Mirror
I did cite real world examples. You took the "how should I know" (with hand waving) approach. I thought perhaps you were being unreasonable due to your unfamiliarity with the particular hardware configuration that I have.
Now I know you're being unreasonable because you're bored, irritable, and I'm the only one feeding you.
-----
You're still wrong. If compiling software for the same architecture gives different results on different hardware, then something is terribly wrong. You can't argue that
-----
I guess we need to define "architecture" and "hardware".
Architecture is what you'll find in the kernel source tree. arm, i386, m68k, Sun, HPPA, etc. Hardware is what you'll find in kernel modules. Chipset patches, ide bus patches, pci bus patches, etc.
Consider the following situation: System A is used to produce generic package binaries for distribution. System B and C have the same architecture but different hardware. Package 1, 2, and 3 are installed on both systems. Package 3 uses libraries included from 2 and Package 2 uses libraries included from Package 1. Developer's lists are full of occurences where upgrading Package 2 on both systems has resulted in Package 3 no longer functioning properly on System B yet still functioning properly on System C. It happens and it drives the package maintainers crazy when they need to go digging through the Makefiles of package 2 and find nothing wrong. Then they start checking the Makefile for Package 1 and find out that some obscure argument has far-reaching consequences.
-----
These differences are touched by on 5% of the code in the world
-----
That would be the 5% of the code that causes headaches for 95% of the programmers. That would be the 5% of the code that requires building from source over prepackaged binaries.
Optimization isn't about squeezing out the last 0.1% of performance. This is about program stability. It takes only one bad instruction in over a billion assembler commands to cause "Abnormal exit" "Program Terminated" or "Segmentation fault".
I'm not trying to pull you away from binary packages. You were pretty hot about saying that there's no additional performance or stability in building from source. That bug that's in 5% of the code says you're wrong.
----- .conf files after compilation and just as easy to do with source packages. If you're paranoid about --enable-with options you're better off building from source so that you know which --enable-with options might be an issue.
./configure options to build MPlayer every time. On Debian it will occaisionally segfault. On LFS it doesn't. The problem may be in libdvdread. That's more reason to build those from source rather than use prepackaged binaries.
Start with like the postfix pacakges, and see how they offer options (even mutually exclusive ones), without requring a user to take the kitchen sink.
-----
All done in
-----
For all I know your RAM is failing
-----
Or you just don't know. Using binary packages isn't going to help you know anything more.
-----
for all I know you build the program wrong.
-----
Or you just don't know. I use the same
-----
How stupid can you possibly be?
-----
The existence of idiosyncracies between binaries compiled for my architecture and packages compiled on my machine does not make me stupid.
-----
This is all a configuration management issues
-----
The binary package maintainers can't produce Makefiles that work for the majority of a target audience AND account for each individual user's specific hardware configuration. Except for select kernel packages (which are necessary) the "one-size-fits-all" approach will always result in a few problems.
-----
If I compile the exact code on two different sets of hardware, but using the exact same software, I'd had better damn well come out with the same generated code,
-----
If you compile source for i386 and the same source for m68k using gcc-3.3.1 linked to glibc-2.3.2 on both machines running the 2.4.24 kernel I hope you don't come up with the same generated code. The difference is more subtle for Pentium vs. AMD but it still exists. The difference is even more subtle for the same processor with different chipsets but still exists. The difference may still exist with the same processor and chipset using different BIOS revisions.
-----
or I have a bug in my hardware, or potentially my toolchain
-----
VIA doesn't consider the ide-scsi emulation in their chipset to be a bug but it sure wreaks havoc with UDMA. I haven't seen this become a big problem under Linux but Win2k sure took a long time to install using INT13h calls to the hard drive.
-----
.deb for mplayer (at least not from Debian). If I built MPlayer from source on my Debian system it would still segfault when playing my DVDs on occaision. MPlayer will loop through Ghost in the Shell all night long on my LFS.
I cited a specific example, Debian
-----
What option would you enable in building from source that Debian doesn't enable? You're mudge with source installation was needing to recompile to remove something that you don't want. AFAIK, Debian packages (and most RPMSs) are typically built with just about everything. If you don't want an option you'll still need to recompile.
-----
Could be any number of things
-----
You're pontificating. I'll post it in my journal when Firefox starts just fine after I build it from source.
-----
Everything is always compiled form source, just not necessarily by you. I'd love to see you expand on this in an attempt to explain how you compiling everything from source guarantees more stability
-----
The stability guarantee is increased by the hardware matching if _every_ library on the system has been built from source. If someone else compiled it they may have been using a different glibc or a different kernel. Case in point: there is no package for the Atheros drivers or the ndiswrapper for Centrino. I have to build those myself. The Atheros drivers (built by me) cause my Debian kernel (built by them), to upchuck on occasion. Another case in point: In Deb 3.0, kernel 2.4.21, with Xf86 4.2.0 the stock radeon drivers would cause Xf86 to lock the system when starting in 1600x1200. All other screen modes worked fine. Compiling the kernel's radeon.o and Xf86's radeon.o from gatos or dri fixed this problem. Another case in point: There is no
Perfect examples illustrating situations where sometimes it's not just the app, sometimes it's not just the driver, sometimes it's not just the compiler... Sometimes it's just that the whole thing needs to be in proper alignment to get flawless stability.
How difficult is --prefix=/usr? Or, from the other standpoint, how difficult is adding /usr/local (to the PATH) and /usr/local/lib (to /etc/ld.so.conf)?
Gentoo compiles glibc, gcc, and kernels from source? I guess I'm not the only one watching compiler scroll for 14 hours at a time.
-----
How much time are you wasting trying to eak out a 5% performance increase?
-----
That 5% performance increase means I don't have to spend $120 for a DVD player that won't be outdated by the next iteration of DVD+.
Of course, since the Radeon7500 is such a |expletive-deleted| of a video card, it also means that I still watch my DVDs on my 19" monitor when that S-video cable could very easily reach my TV. Some day _someone_ will figure out what the radeon driver does to mangle timings sent to the TV-out port. The VESA driver has no timing problems but lacks the performance needed for DVD.
-----
Building from source makes changing options more different. If you later decide you don't want support for a certain feature in a program, you have to recompile it and everything that depends on it. In a binary-package situation, you just download the packages and reinstall
-----
Oh yeah? And what do you do if the binary package includes a certain feature that you decide that you don't want?
Most binary packages are compiled with all available options for precisely the opposite reason that you give.
-----
There are no 'magic' or special optimizations to gain from compiling with custom optimizations. gcc -O2 gives 99% of the speed you will get.
-----
You're right. Mostly. But tell me why Firefox 0.8 refuses to start on my K6-3 400 when it runs happily on my P2 400? Additionally I bet that Firefox 0.8 will run just fine once I build it from source. There is no magic in building single packages from source but if _everything_ is built from source there's a better guarantee on things working.
-----
it took him, on a very modern machine just a year ago, nearly 3 days to have a full working system with X etc
-----
Bah! He's an amateur. I build fully functional systems completely from source in less than 24 hours of compiling time on 400 MHz machines.
That said, unless you're a hobbyist or using really old machines, there's no real need to build from source. In the case of really old machines you have to decide if the extra time at the front-end of building from source is worth the little bit of performance.
In the case of a K6-3 400 MHz machine with UDMA 33 and a VIA Apollo MVP3 chipset the answer is: YES! Building from source let's me watch Fellowship of the Ring without having to buy an external DVD player. Debian yielded choppy playback.
Oh stop already. Unless you're building _every_ library from source then the optimization of later libraries is lost on the precompiled libraries they're dependent on.
It's a nifty feature of Gentoo but how many users really want to wait for glibc? If they don't wait for glibc then are they really gaining anything significant when they build Mozilla manually as opposed to using a nightly build?
Think Tetris. If you don't optimize from the very first row then optimization at row 15 isn't going to save your backside.
Rebuilding selected packages from source in Gentoo is little more than an advertising gimmick. Unless the entire system is built from source the low-level optimizations may actually work against each other.
There is no real "combining the best of both worlds" unless you mean you can use supplied packages and source tarballs for things that don't have packages.
All that aside, though, I like the look and feel of Gentoo and think it'd be a good candidate for the above-average user who's new to Linux.
I think RedHat was working on an .iso for EIBB-Linux until they prematurely moved to the Make Money stage.
.so files masquerading as something else and figures out a way to get Java or Flashplayer to #include them? How long before users go around making everything suid root just because that's the easiest hint to solve their problem that they get from coworkers?
./configure and make as a normal user, but why make install needs to be root.
:-?
Yes, we do agree. I would like to see every home computer running Linux. I guess I'm backtracking on the arguments of why Linux is better, though. When EIBB-Linux reigns the world, how many easily exploitable security flaws will be found in default installations of iptables rules? EIBB-Linux isn't going to attract the real netfilter gurus. While in the past the permissions structure of *nix made this a fairly paltry consideration it's currently being circumvented by beasts like Mozilla. How long before someone figures out how to load the cache with precompiled
I think the best reason for a difficult install is that it can eventually lead the user to recognize the importance of
Once Linux becomes the desktop standard I can envision the following coversations:
Clueless Coworker #1: "I was using my EIBB system last night and and and weren't working correctly. I kept getting errors about and and "
Even More Clueless Coworker #2: "Oh. Just login as "root" and do everything from there. It'll solve that."
CC #1: "But I heard that using root was bad?"
EMCC #2: "That's only what those people using that _hacker_ linux say. The other way you can do it is by just logging in as root and typing chmod u+s since everything's installed by root anyways. Then you won't actually have to be root."
CC #1: "Ohhhhhhh... Okay."
And then people will wonder why spam and zombie boxes still exist. They'll say it's all because of people using that _hacker_ linux. And soon that _hacker_ linux will be illegal. I've heard about it in some dorms at liberal arts colleges a few years ago. The dorm RAs and SAs would issue warnings to students caught using Linux because only someone who wants to do something illegal would use anything but Windows.
Go figure...
-----
Debian doesn't worry about hardware
-----
So what's up with those different kernel packages for MMX, AMD, Pentium, etc. etc. etc.?
-----
So...have they come to get you yet? No? No witch hunt because you are a Pagan running Linux on a Sparc? Hmmm...that's odd
-----
Did you run with an argument by answering your own question? Yes. Yes you did.
The correct answer was "yes". Now your response will be "You must be paranoid."
Linux may win the desktop war but, unless it remains difficult to install, BigBrotherLinux will end up with all the same problems of Windows. I wouldn't mind developing the next OS but rewriting all of my install scripts is sure going to be a PITA and I really don't want to go through the bleeding edge witch hunt again. I'm on the bleeding edge. Why can't the water-cooler gossips just deal with it?
They can dish it out but they can't take it. That's why they want easy-install Linux. They dished it out for years based on Microsoft superiority. Now that the superior MS bubble has finally started to crack they want BigBrotherEasyInstall-Linux so that they won't feel deficient anymore.
-----
Corporate advertisers are the customers, and they pay big bucks for your eyeballs.
-----
Flashback to the Neuromancer video game. Lungs and eyes paid best when you needed cash.
-----
After the demise of X-Files
-----
Interesting point.
I agree that there isn't much to appeal to males in my age category on TV anymore. If we accept the X-Files as being dominantly representative of programming which appeals to young males we can draw conclusions about society.
The X-Files was a show that fed paranoia. Micromanaging causes paranoia. Did the X-Files appeal to young men because we're being micromanaged by old men with Viagra dependencies?
-----
This was the initial install. The kernel should have been built to suit the needs of the hardware in the laptop
-----
Most distros don't autodetect hardware and build a custom kernel for it. They use a precompiled kernel and, if they're good, they may autodetect modules to be loaded. Even so, the Debian kernels tend to be several hundred k larger than any custom kernel that I've built myself. As time goes on and hardware keeps -marching forward this will become a larger and larger problem. In order to be compatible with a broad range of hardware out of the box optimization flags will be left out and extra compatibilities will be built in.
I don't see a problem for the average user, though. The average user isn't going to notice the extra 200k in their kernel or the missing -march=k6 in qiv. Think about it within the context of an evolving society, however. BigBrotherLinux will become popular simply because it suits the needs of the largest segment of the population. Suitability leads to subsidy. Humans, as a species, are suspicious of anything that they don't directly associate with. Suspicion leads to witch hunts. Witch hunts lead to laws. Most often these laws don't correct the witch hunt but seek to outlaw the target. The prevailing message is,"Don't be different or we'll come to get you, too." That's a bit dysfunctional for a society that purports to be diverse. It also suppresses progressive development.
While everyone will be subsidizing BigBrotherLinux through public service contracts (eg. installed at schools, on government infrastructures, in corporate environments) there will be little room left, and additional questioning, for anyone who wants to use something else. The system will be much the same as the ostracization we endured during the HUGE Microsoft boom throughout the 90s. Anyone who wasn't a complete Microsoft advocate was targeted for secret smiles and smirks by the water-cooler gossips.
In a nutshell I advocate Linux being difficult to install. The only driving force behind development and improvement is to demonstrate the existence of a better approach. When the water-cooler gossips are perfect just because they use "Linux" then there will be no better approach than "BigBrotherLinux". When BigBrotherLinux begins to stagnate and bloat there will be no compelling argument against it--unless BSD is still around.
-----
config files to change the "r128" to "vesa".
-----
You're right. You shouldn't have to do that. You probably shouldn't do it at all. Using the VESA driver negates just about every performance optimization that you had.
I see that there's a benefit to Linux not being easy to install. When Linux becomes easy to install then it will be just like Windows. The kernel will be generic (and huge) to account for all possible chipsets and drivers. Only one application will be installed for a given task. If people want to learn about their computer, how it works, and be able to use it properly then it's almost necessary for the system to be difficult. Eg. "Lemme think, learn how to debug pango, fontconfig, xft, glib, gtk, imlib, expat, qiv or go browse the web?" Which would most users choose.
I don't really have a problem with people installing Linux just as an average user and getting an easy install. What I worry about is that, due to the top-down corporate Big Brother iron fist that rules our society, when BigBrotherEasyInstallLinux becomes the popularly accepted (and funded through lucrative and huge government partnerships), will Debian be made illegal because it's different? If BBEI-Linux is easy to install, easy to use, and what the population is familiar with then the logical next question for the clueless majority is: "Why would anyone want to use Debian if it's difficult to install and maintain?" The logical next answer from the clueless majority is: *in low tones* "It's a _hacker_ distribution. They're doing things they shouldn't be doing."
So you see, once the population has EasyInstallBigBrother-Linux, water-cooler gossips come to claim Debian.
It would be better for the world to end.
-----
We then hit "generate" and it created a bunch of C code that went through gcc
-----
This may be true but the code that it generated was most likely NOT the most optimized and streamlined C code for the task. Compiled code begins to break on different machines due to obscure hardware idiosyncracies even if it was compiled from the most correct and streamlined code. It'll break even more often if it's compiled from autogenerated material with extra fluff'n'stuff in it.
Your Telelogic SDL generated SIP client/server may have worked but I guarantee it would be a nightmare to write a fully-fledged corporate application that would run across a broad range of processors and chipsets within the company. I guess this explains why every VP on the planet wants Java webapps. Then they gripe about the slow performance of a 2.4 GHz chip.
-----
a small central piece called the "kernel" and a larger piece that has the applications and drivers
-----
I appreciate THG for putting the foot forward to try and introduce a large user base.
LadyByte: Please tell Humphrey about drivers.
-----
Programmers work out how to do things better, faster, and with less energy
-----
I like programmers as much as the next nerd, but you're On Crack.
Programmers work out how to take shoddy databases and interface them with shoddy operating systems while presenting a bug-ridden interface to the user in a sub-optimal environment. Translation: They code VB to talk to SQL so that people can use Windows to send reports to management using Java plugins on MSIE.
I know that most programmers like to solve problems but they have to eat, too.
Let's try the devil's advocate approach: What if Bill was right? What conditions need to be met in order to make Bill right?
Let's tackle visual programming first:
The reason why visual programming isn't a plausible standard is because we don't have GCC and appropriate toolkit interfaces on hardware chips. In order to make Bill right the entire computing world would need to place not only the OS on a chip (Amiga) but would need to standardize and make chips for the compilers and visual interfaces (X, glib, gtk, tcl/tk, qt, etc.). Even that's only enough for basic user interface visual programming. I can't even imagine what toolkits are necessary for games programmers to do all of their models, raytracing, 3D effects and others.
Maybe if the PC architecture were adapted to allow hot pluggable chips. In order to be compatible, however, it would require frequent freezes of your favorite compiler and toolkits in order for them to be standardized. The system would have to slow down to allow for maximum distribution and population permeation. The last thing you want to do is visually design a software package based on your EEPROM of gcc-3.3.2, Xf86-4.4.40, glib-2.4.0, gtk-2.4.0 and find out that, because of a low-level logic problem in the realm of computer and electrical engineering the program segfaults on home computers using EEPROMs with gcc-3.3.1.
If everyone were using the exact same hardware built at the exact same factories then the platform would be stable enough to allow reliable visual programming on a grand scale. This sort of system would still not guarantee quality, efficient, streamlined, and secure code. This sort of system would guarantee nothing but functionality. Due to the presence of patent law and intellectual property which gave birth to the multitudes of "me-too" hardware and ".100% SoundBlaster compatible" hardware we'll simply never attain that level of platform stability.
That brings around the question of hardware: What would it take for Bill Gates to be right about the price of hardware becoming negligable? First we'd have to remove all of the patent laws and intellectual property regarding chip design and manufacturing. Intel probably won't go for this. It is possible to squeeze out all of the competition (I miss Motorola chips) but the industry is demonstrating that patent law and IP extends to the subcontractors in chip manufacturing as different cards, named the same, which come from different plant locations demonstrate obscure idiosyncracies.
In order for Bill to be right about hardware the world needs to move to a completely open and free model which would make him wrong about visual programming. In order for Bill to be right about visual programming the world would need to standardize on a frozen hardware platform encompassing over 150 source code trees.
There is a third way for Bill Gates to be right. If we could rework the conceptual design of a computer so that it doesn't function like a system of over a trillion light switches then we could create a fast, reliable, and secure hardware platform which doesn't rely on compiled source code to correctly flip the switches.
I know what I'm thinking about for the rest of the day: Holographic computing using preinitialized template holograms.
And why do I keep seeing all of these MS banner ads on /. which repeatedly try to tell me that MS implementation is cheaper, faster, and better?
If night school taught Linux maintenance there wouldn't be any additional intellectual cost to Linux startup and the long-term savings due to better coding, design, and implementation would add up quickly. MS only demonstrates the far reaching power of its megalopoly.
Say you irritate someone in a fairly elevated position and say that person is fairly well connected with someone who can add people to the terror list. So they add your name to the terror list.
So some FBI agent wants to know why you're on the terror list. He gives your name to the local PD as "just check on this guy". The local PD, being fairly bored with nothing better to do, happily and eagerly complies with the new system of checking on potential terrorists. You start to wonder why all of your friends leave the bar about 15 minutes after you show up. They say you're paranoid but everyone keeps looking over your shoulder. You start to get pulled over because your brake lights looked funny, or you were doing 65.2 mph in a 65 zone.
Your boss starts to take a lot more interest in your personal life and becomes offended when you don't open up your life to him. Other managers at work also begin poking and prodding your work. You start to challenge all the extra-special attentin and ask what the purpose of the seeming harassment is. Everyone's eyes glaze over and they accuse of you of being paranoid.
Eventually the FBI agent wears you down with all of this clandestine poking and prodding and investigating. Perhaps you even start to come apart at the seams. The intense scrutiny leaves your nerves on edge and your character becomes more antagonistic.
Where are the reparations? Where's the control on this system? At what point is the initial name-submitter responsible for starting a witch hunt?
Other than that consideration... fine, make your lists. Who gives a good cat's backside?
Miseducation has served you well.
Back in their roots in the 1800s and early 1900s, Republicans WERE Libertarians. They strove to keep government small and out of the way. As the communists started kicking their butts in the polls. however, they had to adapt to appeal to the public opinion of the common half-butt-educated American know-nothing.