Linux takes maybe 120-200mb. That's talking about a kernel (1mb) plus a basic set of OpenGL + X + X driver for cards. That's not much of a 4.5 or 9gb disc. It'd be even less if there was actual work on making it into a standard. Try closer to 250 MB minimum for a working install, probably more, like in the 300 range. More, if you assume a person might need a web-browser, or things like that as well. And a kernel with a full modules tree is more like 10 MB.
My PS2 and GameCube and PS1 and Dreamcast, etc, all seem to save fine. I can get a 16mb USB dongle for 16$ CDN. Why not have it save prefs to a USB dongle? Can you say memory card? They also don't allow arbitrary saving, to conserve on space. PC games are used to, and demand, the ability to save anywhere. That take space. Most games need on the order of 10-20 MB per save file. Looks like that memory card got more expensive.
That's why you have a standard, like MPC was supposed to be a standard about 14 years ago. If you have a set (Athlon/ATI disc, Pentium/ATI disc, etc), you'll be able to make that OS footprint smaller and allow better gaming. Serious gamers only have one of 4 possible combinations (nCr from Athlon or Pentium with ATI or NVidia). Shitty computers with same Cirrus logic bullshit won't be used for this kind of work anyways. You accuse the OP of Red herring, and then go an make one yourself. Game companies don't sell enough volume to be able to be that selective. Only the very big developers (read, id, Epic, EA) can afford to say, only people with the best hardware can run this game. Valve showed with their HL survey that most peopel run on very low-end hardware. Also, pressing discs cost big $$$,as you have to press in large quantities. Pressing four different disc sets for a game is goign to almost always cost more $$$ than not.
If people will put up with PS2 load times, there is nothing to worry about with the much faster and easier to cache (PCs usually have more than 64mb of RAM, the amount of UMA RAM the Xbox has) PC memory and DVD-ROM technology. Umm, yes they will. If I wanted to wait, I'd be playing on a PS2. PC games are a very different breed. We expect fast load times. We expect to be able to save whenever. Its a much more elitest group. Also, load times on a CD from a PC will probably be slower, as the read patterns and filesystem aren't optimized for it.
You bring up an interesting point. I wonder what it would take to create a whole house AC/DC converter. Once in DC its an easy step up or down to the proper voltage for a PC, or any other number of little gadgets that incorporate transformers on them. Actaully, it would be mostly rather trival. However, pulling the current required by your house wouldn't be though. The whole point of using AC is that power doesn't dissappiate over long distances, while it does with DC. Depending on your house, this could or couldn't be a problem.
I can imagine a 45V supply running through to outlets that support the circle jacks of DC/DC converters. Maybe 12V? Most devices that use bulky transformer plugs probably standardize on 9V or less because they are meant to use batteries anyway. PC's run on 5V, no? Try 48V, which is more common than 45V. Even still, why? The AC system works just fine. There is no need to change it.
IF you're on Debian and tried compiling your kernel with kernel-package_8.084, this is just one of hte problems I saw. For whatever reason, that version of kernel-package is extermely broken and not working correctly.
This behavior sounds like your kenrel is being miscompiled, or the kenrel you're using is buggy. What kernel are you using? If you compiled it yourself, did you change anything? What compiler?
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. No you haven't. You have yet to show me a bug report citing cases from any software projects. or a mailing-list e-mail. The cases you've given about your own system, haven't been given with sufficent information for me to make any determination why. I've told you to give me more information, and you refuse -- because you know I'm gonna shatter your poor source-bassed world, and indisputably show that binaries are superior in nearly all cases. But, since you don't wnat that, you won't give me sufficent data to actually do anything. You just ignore me when I evne ask directed questions: like what version of kernel and GLIBC. Fucking idiot. Go home and have fun compiling, and enjoy masterbating in your mother's basement.
Building from sources makes it easier to change an option, and you do NOT need to recompile everything that depends on it. I know, I do it all the time. At worst, you may need to restart some servers that depend on some libs (like when you update openssl). It totally depends on the software in question. BTW, you will have to recompile tons of te things the next time OpenSSL does a ABI-breaking release (which happens nearly every non-bugfix release), as the old apps will simply not be able to use the new library. However, this is irrelevant, as I was talking about recompiling software to remove compiled-in features, which then requires rebuilds of all its dependents.
You are wrong when you say that a source-based distribution is inefficient, because many people can have many different options for the same package, and one binary can not bear all the choices. You misunderstand why I say its inefficent. Given the same piece of software, installing from binary is more efficent because there is less duplication of work, assuming more than one person installs it. That's undisputable.
And yes, binaries can provide the same amount of choices, its just a matter of packaging. Proper packaging solves all the problems. Eventually, there is a thereotical point where the complexity of the binary solution is more than that of the source one, but I haven't seen a case where that's true yet. Doesn't mean it doesn't exist, however.
Your point of the patched binary is stupid really. Even on my P75 (32 MB of memory), which is pretty slow to compile, I would have the patch compiled way before a patched binary appear. The reason is simple : the patch is always available as source first (hey, it's a patch). Given the use of a distribution model, and using the same process to verify a patch, source patching from a distribution takes more time, as both the source and binary have to compile, install and test the patch, but the end-users of a source have to complete the compile and install steps again. Users who don't use a distribution don't count, or who only do it on one machine. They are also not a interesting CM problem either.
I compile everything with athlon-mp on my bi-athlon workstation (a bi Athlon MP 2200+), everything with i386 on my firewall box (a Pentium P75), everything with athlon-xp on my other box (which have an old Athlon 500).
Why should have to cripple my main workstation ? You're not. The fact you make that statement show you simp[y don't know what you're talking about. I'm not even going to discuss this, but look up I/O-bound vs. CPU-bound tasks.
As for the support, it is done by the authors of software, in a true free software spirit. Corprations don't like that. They want paid support, with a legal contract, and libality, so when something breaks, they can sue someone.
As for the support, it is done by the authors of software, in a true free software spirit. When I have a package that do not compile, I do a fast analysis (well, because I can, not everyone can, I agree), and I make a bug report or go on the ML. I always have a fix or a workaround within 24 hours. I do not spend 3 hours searching why sth does not compile, when it used to compile before.
As all is automated, I do not spend time monitoring anything. I change my package versions in my XML, launch nALFS, select what to install, and it does the rest. Well, sometimes, the download locations or the format of the package can change, so I may have to change that too. These two statements side by side prove your system isn't automated. Idiot.
No, it isn't. You're giving poor thereotical examples to problesm that don't occur like that. Usually, the kind of issues you are citing are hardware-independent software configuration issues, caused by external package 4 you forgot to mention, that's on C and not on B. Get off it already. You're inablity to actaully know what you're talking about or cite real world examples makes you look more foolish.
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.
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.
Optimization isn't about squeezing out the last 0.1% of performance. This is about program stability. Bullshit. It it was about stability, it would be called Stablization not Optimization. Damn you're dumb.
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. No it doesn't. All it says is that some programmer made a mistake. Compiling from source as opposed to using a binary package isn't goign to make that bug go away. The only extra risk added is that the packager makes a mistake -- but you have that potential risk if oyu don't compile everythign yourself anyway (i.e., using Gentoo still exposes you to that risk, and even potentially LFS, if you take the instructions as gospel).
Or you just don't know. Using binary packages isn't going to help you know anything more. Of course I don't know, because I already told you (and I'll make this bold, since you have a serious reading comp. problem) You didn't give me sufficent information to tell me why.
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. You still haven't given enough information. What options? What versions? What version of GCC? What version of GLIBC? I seriously doubt things were 100% the same. Determining what was different will probably determine what the cause was. You still havne't given solid proof to why building from source is better, just ancedotal evidence, that can be used to disprove your point, provided you give sufficent amounts of it.
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. Yes they can. Show me a case in which they can't, and how it matters. I bet you a nickle its just a matter of packaging correctly. You assume that binary means a one-size-fits-all approach. It doesn't, at all, provided the packakge mantainers take the time to do their job correctly.
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 fact that you dig down to pointing at different architectures shows that you're grasping for straws. Of course its going to be different for different architectures. How fucking dumb are you?
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. These differences are touched by on < 5% of the code in the world. And the only really differences are in what SIMD sets each processor supports. The rest is how to get optimal performance out of both processors, but that's not as big as people think.
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. And this is relevant how so, to what we are talking about?
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. This shows you didn't read my reply very well. You asked about binaries including packages that werent' kitchen sink, and my reply was (and still is): Go look at debian, very closely. 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.
You're pontificating. I'll post it in my journal when Firefox starts just fine after I build it from source. No, it just shows I'm not dumb enough to troubleshoot based on such little information. For all I know your RAM is failing.
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. Differing Glibc doesn't matter as long as it was compiled against an older version in the same series (i.e., 2.1 is upwards compatible to 2.3, but you can't run code compiled against 2.3 on 2.1). The exception of course, is when your glibc is heavily patched. The kernel doesn't matter at all unless you're talking about kernel modules.
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. You still haven't given enough information here to explain why. What version of the drivers? Which debian kernel? It could still be any number of things, and you still haven't given sufficent information for anyone to determine your problem. The same with your other examples: its a known fact that the Radeon DRI module shipped with XFree86 4.2 is buggy as all-hell. Don't blame the distribution for the fault of the software writers. As for your mplayer build, for all I know you build the program wrong.
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. And compiling on your hardware doesn't put things in 'proper alignment'. How stupid can you possibly be? This is all a configuration management issues, and all relatively straightforward ones (even if coming up with the optimal solution is difficult). 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, or I have a bug in my hardware, or potentially my toolchain. Remember, this is all binary -- 1's and 0's. The hardware compiled on has no magic here, it just runs code. It only matters if the hardware is buggy, and doesn't run the code correctly, or the program making the code (Read compiler) is buggy, and doesn't generate the code correctly in all cases (which can occasionally be hardware dependent).
Most binary packages are compiled with all available options for precisely the opposite reason that you give. I cited a specific example, Debian. Even in a source-based world, packages where options have to be compiled in are usually all or nothing anyway -- there's usually very few options that can only be compiled in, and not as a shared library or a dynamically-loaded one. For most packages where this isn't the case, Debian provides multiple versions for all the common combinations of potential options.
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? Could be any number of things. Assuming the package was compiled wrong based on that one piece of information is stupid, as is making an assumption baed on that little aomount of information.
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. 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. Unless you're auditing all the source before you're compiling it, it doesn't, unless you know something I don't.
A proper setup binary package system can give the flexability of buildng from source, without the hassle of it. Debian is a perfect example of this, and the almost excessive modularity of their packages. Look at their packaging setup of KDE and XFree for two good examples (in unstable).
Building from source is uncommon. Most Linux users don't do it. The majority that do, only do it on desktop systems, not high-end servers and workstations. The corporate world tends to shun awya from compiling code -- they want easy, ready-to-use components wherever they can.
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.
A Source-based distribution is inefficent, in that many people are doing work (compiling code) that only needs to be done once.
There are no 'magic' or special optimizations to gain from compiling with custom optimizations. gcc -O2 gives 99% of the speed you will get. Plus, the higher-end -march optimizers (like the P4, and Athlon XP) can still occasionally generated buggy SIMD ops. The reality of it is -- is the few programs that do need high-end optimizations will have then enabled in the build system, or will have hand-written assembly already there. A bigger speed boost would be given by switching compilers, then by trying to tweak out GCC.
Time to recover on a source-based distribution, say if an exploit will be released, will be higher than on a binary-based distribution, as it takes more time to compile a patch then to just install an already patched binary.
Using source means all the configuration management issues are in your hands. The reality of it is, you're probably not that great at handling those issues on a wide scale. That's why distributions exist: they solve these problems for you. Why do work you can already use for free?
AFAIK, none of the source-based distributions will support your installation officaly, for obvious reasons.
Or the Patriot Defense System, which routinely targeted friendly aircraft during development, failed miserably the first time it was put into use(for a use it was never intended- it's never been used for what it was originally designed for, shooting down planes) and then 10+ years later was used again and resulted in the deaths of dozens of UK soldiers because it couldn't tell the difference between a helicopter traveling at less than 100 kt and an enemy missile traveling over the speed of sound? Don't blame the technology when its being used in perverted ways. You yourself said that is meant for shooting down planes. It should not have shocked anyone when they tried to use it for something else and it didn't work.
The defense department is famous for bidding scandals(if contracts are put out to bid at all), and being happy to look the other way and fudge the requirements(or ignore them completely) if the system fails to meet original requirements. I'd like you to name a bidding scandal then. Also, requirements are usually dropped because they were pointless in teh first place or just plain wrong. Valid requirements are rarely relaxed. Remember, requirements documents are written by committe. What sounds good on paper frequently doesn't work in real life. Anyone who's spent even a day on a goverment contract knows this.
This country needs three things. First, a true capitalist system for defense contractors. You want to sell the Army a tank? Fine. You can do so all on your own, without a single fucking dime, and then try and sell it. If it can't compete, too bad, your company goes under- that's the way capitalism works. That's completely impractical. It costs too much to design a tank -- only about 3 or 4 companies in the United State could do it. Furthermore, the gov't doesn't want your tank, they want their tank. Most contracts work like this:
The goverment decides they want something
They hire someone to design it for them
They then pay someone to make it
Its done this way on purpose, because the goverment likes to be in control.
Second, defense contractors need to be held responsible for when their products fail. Refunds for starters, contracts that can be invalidated on failure, civil/criminal punishments for gross design/construction failures. Actually, they are held liable. There is this long whole process called testing, the contractor is liable until the item passes the tests. The gov't won't assume liability until it passes tests.
Third, absolutely, positively, no secret budgets of any kind. I am entirely pissed off with the pentagon filling up with all the kids who had secret treehouse clubs when they were kids and want to do the same shit now that they're 40. The fact that you bring this up at all proves that you have no idea WTF you are talking about. People outside the defence community rarely understand the need for such paranoia or why we have it. But let me put it to you this way: how many security leaks do we have and have had in this country? The answer: not many. The reason: because the gov't takes security seriously, and understands it better to secure too much than secure too little.
1: NV and ATI could make up their own OSS license. Lets call it the "We Need To Hide Stuff" license. They take their existing codebase and print it out. They then take a black magic marker to the printout and cross off all of the IP related stuff. They then scan the documents into Acrobat distiller and release it as a PDF. Add a statement that the code is their property under the WNTHS license and cannot be used by others, and all changes should be sent to NVidia. Problem solved. It's OSS.
This isn't open source. This is you can look at our code, but you can't do shit with it source. Its not even compilable without those confidental components. You fail to show what this gains us. People clamoring for open source drivers need the whoel source, and in a form you can build in. What does this give you?
2: I have never seen a processor designer "hide" their chip specs. Intel doesn't. AMD doesn't. What makes NV different? Unless they have unlicensed hardware in their product, there is no reason for them to hide what they have. WTF are you talking about? The inner workings of AMD and Intel's chips are very much far away from the public eye. The public porition is the ABI and API to use the processor, which has to be made public -- otherwise no one would be able to use the processor.
This makes me want to throw up. The last motherboard purchase I made, it was a chore finding one with the _least_ amount of features. Need an AMR riser slot? Fuck no, I'd rather have the PCI slot back. You do realize it costs much less to put a AMR or CNR slot on a motherboard then a PCI slot right?
Need integrated sound? No, integrated sound makes my already bad speakers sound worse. It must've been tough figuring out how to make a decade's worth of improvements in technology amount to nothing. I have an ISA soundblaster from 10 years ago that sounds better than the onboard sound on my last motherboard. Now its obvious you're trolling. Say what you want about AC97-based onboard sound (which nearly everythign is), but its good enough. Your speakers are much more likely the problem. The long and short is that all PC sounds cards equally suck until you get to professional grade gear.
Need integrated video? I won't begrudge you this. Some people build clusters with their motherboards, and a video card is needed to boot, but if I have a choice I won't buy a mobo with integrated video. What does having this cost you? Its not like you have to use it, or that boards with onboard video cost signifcantly more.
Amateur radio has just as much right to exist as anything else in the spectrum.Actually, by law, Amateur Radio has more right to exist in the spectrum in question that broadband over power. Sorry. Not all portions of the EM spectrum are equally free in the US.
No, it will sell for tons of money. The spectrum is bundled up now -- tons of companies want it, but no one can have it. So demand is artifically high. When the HDTV spectrum is freed, there will be a feeding frenzy in an attempt to gobble up the spectrum. Since the FCC has to approve the use of hte spectrum, demand on it stays high always -- if no one wants to pay, then the FCC can just hold off on licensing its use.
No, its only libelous if you are attempting to use the statements to damage a person's reputation or character. That's why its nearly impossible to win a slander or libel case in the USA -- unless the person slips up and writes down that they're intentionally damaging someone's character, you have no proof that'll hold up in court.
Now in the rest of the world, the standard is much different.
Sniffing only works on the same segment. It's totally useless on a switched network, which includes most networks these days. Its easy enough to trick a switch into "hub" mode simply by throwing arp traffic everywhere. More importantly, most switches and routers have a remote monitoring feature that allows you to copy all packets to an interface for monitoring purposes. Gain control of the network gear and then switching does nothing. Most "switched" networks aren't really switched either due to poor planning in many places.
Additionally, if the knock sequence is has a sufficiently number of ports, it's simply going to look like a port scan. Which are fairly commonplace these days No, because if you do a "port scan" and then connect and hold a session on port 22, that looks obvious.
Bullshit. Whatever makes you think it is that easy to build drivers for graphics cards that can just pull the source to the old one and recompile? Absolute nonsense. At best, that might be true within a single driver family, and even then, some hacking is required to update PCI IDs, and possibly the list of features the card supports.
Every different card line however, requries a different underlying layer to handle all the little tweaks and get maximium performance. Its not nearly as simple as you think.
Have you ever doen any hardware programming before? The fact that nVidia has a single driver serving such a wide line of cards is quite a feat. I've seen drivers that had to have 2 seperate code paths simply because of revisions to firmeware within the same "Version" of the software.
While the BigDig itself is quite a feat in every regard (engineering, technological, political, etc.) I personally, worked on the software driving the BigDig's traffic managment system (TMS). The completed system is a quite a feat, allowing their operators to monitor every asepect of the roadway.
The system features a complete CCTV network, espousing the entire system. It provides comprehensive monitoring and control of every device attached to the tunnel and supporting buildings, including traffic signs, message signs, fire alarms, smoke detectors, ventilation fans, electrical subsystems.
You name it, its connected to the TMS -- everything can be monitored and controled from there. Obviously, its not the only manner to control; everything has a redundant control system, so everything could be controlled if the system shuts down.
The system also features intelligent accident management and response: it can automatically balance responses to mulitiple accidents, and automatically recommend responses based on roadway conditions. For example, if a accidnet occurs shutting down the two center lanes, it will automatically PLace red X's on the lane signals, display accident warning messages on the signs, and even change the radio message as appropate. All the operator has to do is review the recommend actions, remove any he doesn't want, and activate. The software takes care of handling everything else.
Its not quite over yet. I-93 Elevated isn't gone yet, as I-93 isn't finished yet. I-93SB is still jsut a partial opening, not all of the lanes are open yet. That's still another full year down the road yet, possibly longer.
This is incorrect. The I-93 section of the Artery is toll free.
I-90 (the Mass Pike) extension is toll, on the return (Westbound) side of the tunnel, comming out of the airport. It was previously $4 dollars for cars when I last working on the project. FWIW, the Eastbound section is toll too, but you pay them before you enter the section of the highway that belongs to the CA/T.
Slashdot Mirror
Linux takes maybe 120-200mb. That's talking about a kernel (1mb) plus a basic set of OpenGL + X + X driver for cards. That's not much of a 4.5 or 9gb disc. It'd be even less if there was actual work on making it into a standard.
Try closer to 250 MB minimum for a working install, probably more, like in the 300 range. More, if you assume a person might need a web-browser, or things like that as well. And a kernel with a full modules tree is more like 10 MB.
My PS2 and GameCube and PS1 and Dreamcast, etc, all seem to save fine. I can get a 16mb USB dongle for 16$ CDN. Why not have it save prefs to a USB dongle? Can you say memory card?
They also don't allow arbitrary saving, to conserve on space. PC games are used to, and demand, the ability to save anywhere. That take space. Most games need on the order of 10-20 MB per save file. Looks like that memory card got more expensive.
That's why you have a standard, like MPC was supposed to be a standard about 14 years ago. If you have a set (Athlon/ATI disc, Pentium/ATI disc, etc), you'll be able to make that OS footprint smaller and allow better gaming. Serious gamers only have one of 4 possible combinations (nCr from Athlon or Pentium with ATI or NVidia). Shitty computers with same Cirrus logic bullshit won't be used for this kind of work anyways.
You accuse the OP of Red herring, and then go an make one yourself. Game companies don't sell enough volume to be able to be that selective. Only the very big developers (read, id, Epic, EA) can afford to say, only people with the best hardware can run this game. Valve showed with their HL survey that most peopel run on very low-end hardware.
Also, pressing discs cost big $$$,as you have to press in large quantities. Pressing four different disc sets for a game is goign to almost always cost more $$$ than not.
If people will put up with PS2 load times, there is nothing to worry about with the much faster and easier to cache (PCs usually have more than 64mb of RAM, the amount of UMA RAM the Xbox has) PC memory and DVD-ROM technology.
Umm, yes they will. If I wanted to wait, I'd be playing on a PS2. PC games are a very different breed. We expect fast load times. We expect to be able to save whenever. Its a much more elitest group. Also, load times on a CD from a PC will probably be slower, as the read patterns and filesystem aren't optimized for it.
You bring up an interesting point. I wonder what it would take to create a whole house AC/DC converter. Once in DC its an easy step up or down to the proper voltage for a PC, or any other number of little gadgets that incorporate transformers on them.
Actaully, it would be mostly rather trival. However, pulling the current required by your house wouldn't be though.
The whole point of using AC is that power doesn't dissappiate over long distances, while it does with DC. Depending on your house, this could or couldn't be a problem.
I can imagine a 45V supply running through to outlets that support the circle jacks of DC/DC converters. Maybe 12V? Most devices that use bulky transformer plugs probably standardize on 9V or less because they are meant to use batteries anyway. PC's run on 5V, no?
Try 48V, which is more common than 45V. Even still, why?
The AC system works just fine. There is no need to change it.
IF you're on Debian and tried compiling your kernel with kernel-package_8.084, this is just one of hte problems I saw. For whatever reason, that version of kernel-package is extermely broken and not working correctly.
This behavior sounds like your kenrel is being miscompiled, or the kenrel you're using is buggy. What kernel are you using? If you compiled it yourself, did you change anything? What compiler?
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.
No you haven't. You have yet to show me a bug report citing cases from any software projects. or a mailing-list e-mail. The cases you've given about your own system, haven't been given with sufficent information for me to make any determination why. I've told you to give me more information, and you refuse -- because you know I'm gonna shatter your poor source-bassed world, and indisputably show that binaries are superior in nearly all cases. But, since you don't wnat that, you won't give me sufficent data to actually do anything. You just ignore me when I evne ask directed questions: like what version of kernel and GLIBC. Fucking idiot. Go home and have fun compiling, and enjoy masterbating in your mother's basement.
Building from sources makes it easier to change an option, and you do NOT need to recompile everything that depends on it. I know, I do it all the time. At worst, you may need to restart some servers that depend on some libs (like when you update openssl).
It totally depends on the software in question. BTW, you will have to recompile tons of te things the next time OpenSSL does a ABI-breaking release (which happens nearly every non-bugfix release), as the old apps will simply not be able to use the new library. However, this is irrelevant, as I was talking about recompiling software to remove compiled-in features, which then requires rebuilds of all its dependents.
You are wrong when you say that a source-based distribution is inefficient, because many people can have many different options for the same package, and one binary can not bear all the choices.
You misunderstand why I say its inefficent. Given the same piece of software, installing from binary is more efficent because there is less duplication of work, assuming more than one person installs it. That's undisputable.
And yes, binaries can provide the same amount of choices, its just a matter of packaging. Proper packaging solves all the problems. Eventually, there is a thereotical point where the complexity of the binary solution is more than that of the source one, but I haven't seen a case where that's true yet. Doesn't mean it doesn't exist, however.
Your point of the patched binary is stupid really. Even on my P75 (32 MB of memory), which is pretty slow to compile, I would have the patch compiled way before a patched binary appear. The reason is simple : the patch is always available as source first (hey, it's a patch).
Given the use of a distribution model, and using the same process to verify a patch, source patching from a distribution takes more time, as both the source and binary have to compile, install and test the patch, but the end-users of a source have to complete the compile and install steps again. Users who don't use a distribution don't count, or who only do it on one machine. They are also not a interesting CM problem either.
I compile everything with athlon-mp on my bi-athlon workstation (a bi Athlon MP 2200+), everything with i386 on my firewall box (a Pentium P75), everything with athlon-xp on my other box (which have an old Athlon 500).
Why should have to cripple my main workstation ?
You're not. The fact you make that statement show you simp[y don't know what you're talking about. I'm not even going to discuss this, but look up I/O-bound vs. CPU-bound tasks.
As for the support, it is done by the authors of software, in a true free software spirit.
Corprations don't like that. They want paid support, with a legal contract, and libality, so when something breaks, they can sue someone.
As for the support, it is done by the authors of software, in a true free software spirit. When I have a package that do not compile, I do a fast analysis (well, because I can, not everyone can, I agree), and I make a bug report or go on the ML. I always have a fix or a workaround within 24 hours. I do not spend 3 hours searching why sth does not compile, when it used to compile before.
As all is automated, I do not spend time monitoring anything. I change my package versions in my XML, launch nALFS, select what to install, and it does the rest. Well, sometimes, the download locations or the format of the package can change, so I may have to change that too.
These two statements side by side prove your system isn't automated. Idiot.
No, it isn't. You're giving poor thereotical examples to problesm that don't occur like that. Usually, the kind of issues you are citing are hardware-independent software configuration issues, caused by external package 4 you forgot to mention, that's on C and not on B.
Get off it already. You're inablity to actaully know what you're talking about or cite real world examples makes you look more foolish.
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.
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.
Optimization isn't about squeezing out the last 0.1% of performance. This is about program stability.
Bullshit. It it was about stability, it would be called Stablization not Optimization. Damn you're dumb.
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.
No it doesn't. All it says is that some programmer made a mistake. Compiling from source as opposed to using a binary package isn't goign to make that bug go away. The only extra risk added is that the packager makes a mistake -- but you have that potential risk if oyu don't compile everythign yourself anyway (i.e., using Gentoo still exposes you to that risk, and even potentially LFS, if you take the instructions as gospel).
Or you just don't know. Using binary packages isn't going to help you know anything more.
Of course I don't know, because I already told you (and I'll make this bold, since you have a serious reading comp. problem) You didn't give me sufficent information to tell me why.
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.
You still haven't given enough information. What options? What versions? What version of GCC? What version of GLIBC? I seriously doubt things were 100% the same. Determining what was different will probably determine what the cause was. You still havne't given solid proof to why building from source is better, just ancedotal evidence, that can be used to disprove your point, provided you give sufficent amounts of it.
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.
Yes they can. Show me a case in which they can't, and how it matters. I bet you a nickle its just a matter of packaging correctly. You assume that binary means a one-size-fits-all approach. It doesn't, at all, provided the packakge mantainers take the time to do their job correctly.
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 fact that you dig down to pointing at different architectures shows that you're grasping for straws. Of course its going to be different for different architectures. How fucking dumb are you?
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.
These differences are touched by on < 5% of the code in the world. And the only really differences are in what SIMD sets each processor supports. The rest is how to get optimal performance out of both processors, but that's not as big as people think.
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.
And this is relevant how so, to what we are talking about?
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.
This shows you didn't read my reply very well. You asked about binaries including packages that werent' kitchen sink, and my reply was (and still is): Go look at debian, very closely. 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.
You're pontificating. I'll post it in my journal when Firefox starts just fine after I build it from source.
No, it just shows I'm not dumb enough to troubleshoot based on such little information. For all I know your RAM is failing.
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.
Differing Glibc doesn't matter as long as it was compiled against an older version in the same series (i.e., 2.1 is upwards compatible to 2.3, but you can't run code compiled against 2.3 on 2.1). The exception of course, is when your glibc is heavily patched.
The kernel doesn't matter at all unless you're talking about kernel modules.
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.
You still haven't given enough information here to explain why. What version of the drivers? Which debian kernel? It could still be any number of things, and you still haven't given sufficent information for anyone to determine your problem. The same with your other examples: its a known fact that the Radeon DRI module shipped with XFree86 4.2 is buggy as all-hell. Don't blame the distribution for the fault of the software writers. As for your mplayer build, for all I know you build the program wrong.
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.
And compiling on your hardware doesn't put things in 'proper alignment'. How stupid can you possibly be? This is all a configuration management issues, and all relatively straightforward ones (even if coming up with the optimal solution is difficult). 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, or I have a bug in my hardware, or potentially my toolchain. Remember, this is all binary -- 1's and 0's. The hardware compiled on has no magic here, it just runs code. It only matters if the hardware is buggy, and doesn't run the code correctly, or the program making the code (Read compiler) is buggy, and doesn't generate the code correctly in all cases (which can occasionally be hardware dependent).
Most binary packages are compiled with all available options for precisely the opposite reason that you give.
I cited a specific example, Debian. Even in a source-based world, packages where options have to be compiled in are usually all or nothing anyway -- there's usually very few options that can only be compiled in, and not as a shared library or a dynamically-loaded one. For most packages where this isn't the case, Debian provides multiple versions for all the common combinations of potential options.
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?
Could be any number of things. Assuming the package was compiled wrong based on that one piece of information is stupid, as is making an assumption baed on that little aomount of information.
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.
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. Unless you're auditing all the source before you're compiling it, it doesn't, unless you know something I don't.
Or the Patriot Defense System, which routinely targeted friendly aircraft during development, failed miserably the first time it was put into use(for a use it was never intended- it's never been used for what it was originally designed for, shooting down planes) and then 10+ years later was used again and resulted in the deaths of dozens of UK soldiers because it couldn't tell the difference between a helicopter traveling at less than 100 kt and an enemy missile traveling over the speed of sound?
Don't blame the technology when its being used in perverted ways. You yourself said that is meant for shooting down planes. It should not have shocked anyone when they tried to use it for something else and it didn't work.
The defense department is famous for bidding scandals(if contracts are put out to bid at all), and being happy to look the other way and fudge the requirements(or ignore them completely) if the system fails to meet original requirements.
I'd like you to name a bidding scandal then. Also, requirements are usually dropped because they were pointless in teh first place or just plain wrong. Valid requirements are rarely relaxed. Remember, requirements documents are written by committe. What sounds good on paper frequently doesn't work in real life. Anyone who's spent even a day on a goverment contract knows this.
This country needs three things. First, a true capitalist system for defense contractors. You want to sell the Army a tank? Fine. You can do so all on your own, without a single fucking dime, and then try and sell it. If it can't compete, too bad, your company goes under- that's the way capitalism works.
That's completely impractical. It costs too much to design a tank -- only about 3 or 4 companies in the United State could do it. Furthermore, the gov't doesn't want your tank, they want their tank. Most contracts work like this:
Its done this way on purpose, because the goverment likes to be in control.
Second, defense contractors need to be held responsible for when their products fail. Refunds for starters, contracts that can be invalidated on failure, civil/criminal punishments for gross design/construction failures. Actually, they are held liable. There is this long whole process called testing, the contractor is liable until the item passes the tests. The gov't won't assume liability until it passes tests.
Third, absolutely, positively, no secret budgets of any kind. I am entirely pissed off with the pentagon filling up with all the kids who had secret treehouse clubs when they were kids and want to do the same shit now that they're 40.
The fact that you bring this up at all proves that you have no idea WTF you are talking about. People outside the defence community rarely understand the need for such paranoia or why we have it. But let me put it to you this way: how many security leaks do we have and have had in this country? The answer: not many. The reason: because the gov't takes security seriously, and understands it better to secure too much than secure too little.
1: NV and ATI could make up their own OSS license. Lets call it the "We Need To Hide Stuff" license. They take their existing codebase and print it out. They then take a black magic marker to the printout and cross off all of the IP related stuff. They then scan the documents into Acrobat distiller and release it as a PDF. Add a statement that the code is their property under the WNTHS license and cannot be used by others, and all changes should be sent to NVidia. Problem solved. It's OSS.
This isn't open source. This is you can look at our code, but you can't do shit with it source. Its not even compilable without those confidental components. You fail to show what this gains us. People clamoring for open source drivers need the whoel source, and in a form you can build in. What does this give you?2: I have never seen a processor designer "hide" their chip specs. Intel doesn't. AMD doesn't. What makes NV different? Unless they have unlicensed hardware in their product, there is no reason for them to hide what they have.
WTF are you talking about? The inner workings of AMD and Intel's chips are very much far away from the public eye. The public porition is the ABI and API to use the processor, which has to be made public -- otherwise no one would be able to use the processor.
This makes me want to throw up. The last motherboard purchase I made, it was a chore finding one with the _least_ amount of features. Need an AMR riser slot? Fuck no, I'd rather have the PCI slot back.
You do realize it costs much less to put a AMR or CNR slot on a motherboard then a PCI slot right?
Need integrated sound? No, integrated sound makes my already bad speakers sound worse. It must've been tough figuring out how to make a decade's worth of improvements in technology amount to nothing. I have an ISA soundblaster from 10 years ago that sounds better than the onboard sound on my last motherboard.
Now its obvious you're trolling. Say what you want about AC97-based onboard sound (which nearly everythign is), but its good enough. Your speakers are much more likely the problem. The long and short is that all PC sounds cards equally suck until you get to professional grade gear.
Need integrated video? I won't begrudge you this. Some people build clusters with their motherboards, and a video card is needed to boot, but if I have a choice I won't buy a mobo with integrated video.
What does having this cost you? Its not like you have to use it, or that boards with onboard video cost signifcantly more.
Amateur radio has just as much right to exist as anything else in the spectrum.Actually, by law, Amateur Radio has more right to exist in the spectrum in question that broadband over power. Sorry. Not all portions of the EM spectrum are equally free in the US.
No, it will sell for tons of money. The spectrum is bundled up now -- tons of companies want it, but no one can have it. So demand is artifically high. When the HDTV spectrum is freed, there will be a feeding frenzy in an attempt to gobble up the spectrum. Since the FCC has to approve the use of hte spectrum, demand on it stays high always -- if no one wants to pay, then the FCC can just hold off on licensing its use.
No, its only libelous if you are attempting to use the statements to damage a person's reputation or character. That's why its nearly impossible to win a slander or libel case in the USA -- unless the person slips up and writes down that they're intentionally damaging someone's character, you have no proof that'll hold up in court.
Now in the rest of the world, the standard is much different.
Sniffing only works on the same segment. It's totally useless on a switched network, which includes most networks these days.
Its easy enough to trick a switch into "hub" mode simply by throwing arp traffic everywhere. More importantly, most switches and routers have a remote monitoring feature that allows you to copy all packets to an interface for monitoring purposes. Gain control of the network gear and then switching does nothing. Most "switched" networks aren't really switched either due to poor planning in many places.
Additionally, if the knock sequence is has a sufficiently number of ports, it's simply going to look like a port scan. Which are fairly commonplace these days
No, because if you do a "port scan" and then connect and hold a session on port 22, that looks obvious.
No, this was because Linux/Alpha at that point didn't have an ld.so. Everything was statically compiled, which is where the size increase came from.
Bullshit. Whatever makes you think it is that easy to build drivers for graphics cards that can just pull the source to the old one and recompile? Absolute nonsense. At best, that might be true within a single driver family, and even then, some hacking is required to update PCI IDs, and possibly the list of features the card supports.
Every different card line however, requries a different underlying layer to handle all the little tweaks and get maximium performance. Its not nearly as simple as you think.
Have you ever doen any hardware programming before? The fact that nVidia has a single driver serving such a wide line of cards is quite a feat. I've seen drivers that had to have 2 seperate code paths simply because of revisions to firmeware within the same "Version" of the software.
While the BigDig itself is quite a feat in every regard (engineering, technological, political, etc.)
I personally, worked on the software driving the BigDig's traffic managment system (TMS). The completed system is a quite a feat, allowing their operators to monitor every asepect of the roadway.
The system features a complete CCTV network, espousing the entire system. It provides comprehensive monitoring and control of every device attached to the tunnel and supporting buildings, including traffic signs, message signs, fire alarms, smoke detectors, ventilation fans, electrical subsystems.
You name it, its connected to the TMS -- everything can be monitored and controled from there. Obviously, its not the only manner to control; everything has a redundant control system, so everything could be controlled if the system shuts down.
The system also features intelligent accident management and response: it can automatically balance responses to mulitiple accidents, and automatically recommend responses based on roadway conditions. For example, if a accidnet occurs shutting down the two center lanes, it will automatically PLace red X's on the lane signals, display accident warning messages on the signs, and even change the radio message as appropate. All the operator has to do is review the recommend actions, remove any he doesn't want, and activate. The software takes care of handling everything else.
Its not quite over yet. I-93 Elevated isn't gone yet, as I-93 isn't finished yet. I-93SB is still jsut a partial opening, not all of the lanes are open yet. That's still another full year down the road yet, possibly longer.
This is incorrect. The I-93 section of the Artery is toll free.
I-90 (the Mass Pike) extension is toll, on the return (Westbound) side of the tunnel, comming out of the airport. It was previously $4 dollars for cars when I last working on the project. FWIW, the Eastbound section is toll too, but you pay them before you enter the section of the highway that belongs to the CA/T.
As I said in an eariler post, this isn't a cruise missle, more like a self-guiding rocket.
A real cruise missle can travel at mouch lower altitudes than this thing can (10 fT), much master (~0.8 Mach) and has a much larger range.
When he can do that on 5K.. he'll get hired.