I have yet to use any PVR services, but from what I understand they can make recommendations of shows that you are likely to enjoy based on your viewing habits. I am not sure if you can opt out for privacy reasons. But a better alternative to stagnation might be to turn the TV off now and then.
Just a nit I have to pick, but 802.2 Ethernet is not a broadband medium. Cable is broadband, because you have "channels". A school that only has ethernet connectivity would be said to provide baseband connectivity.
Just be glad you're not an Apple fringe (clone supporting), Windows Using, GNU advocating, C=64 loving BeOS bigot. Even if I secured the funds for a New Macintosh, I'd only be slightly sated, resentful of Chairman Jobs, and wistful for OpenBeOS' unveiling.
In the meantime, I'm slashdotting on Win2k, short on 72pin true Parity for my TurboSlab Color (Which isn't supported by Linux, or even NetBSD!) and still trying to get Darwin going on my PowerCenter Mac clone. (Why PowerTower, but not PowerCenter!) -castlan
I'd have to argue against the "sex appeal" arguement. Doesn't Be Inc. have a claim of Prior Art, in light of how often the BeOS made Jean Louis Gassee's nipples hard? Just a bit of enlightenment.... which reminds me, wouldn't Enlightenment also have a claim to prior art?
You have a point. Most people don't know it, but modern processors use a hazardous combination of Potassium Fluoride and spent Plutonium to regulate clock speed, which is the real reason that it isn't safe to overclock your computer!
That density is especially thick with server CPUs, especially the Xeon. That is why, to date, nobody has set off large enough of a reaction to be deadly with overclocking PCs, but that is not the case with Xeons, whose Plutonium content is dangerously close to the Critical Mass. And you thought your Intel CPU ran hot! Everybody who runs Xeon servers knows better than to play with the clock speed.
In fact, that is why you can't ususally buy Xeons without ECC RAM, the radiation put off by the computation would too readily disrupt the memory state information. What, you bought that nonsense about solar flares or other sources of random radiation causing bit decay? Of, and FYI, don't run Distributed.net or Seti@home on your Xeon if you have fillings or a mercury thermometer in the area, unless you are interested in a direct demonstrations of fusion in action.
Really, since the Cold war had ended, Microprocessors have been constantly dropping in price. Why was this phenomenon never observerved until the 80? Moore's Law my ass, how about "military surplus in action." It is much too expensive to store all of this spent plutonium in federal compunds. So the FCC had to ensure that computers had sufficient shielding, and now, there you go. Let me reiterate that ever since the "Pentium Pro" (Plutonium Recycling Operation) and with each new generation of CPU, active cooling remains a matter of utmost priority.
Really, they would have just put it in the drinking water supplies to distribute the threat amongst all of our nations' citizens (like taxes and fluoride) except that in secret military tests they found that the subjects teeth and bones started to glow in the dark, which would have been too obvious to cover up for long. So they stationed the subjects in parts of Japan, Las Vegas, and tropical locations so that the glowing would be concealed by all of the Neon Lights and overpowering sun (causing a sun tan, to help cover the light emissions) and classisifed the research.
Well, in any case, I highly recommend tht you don't ever "crack" one of the more recent Xeons apart. Rather, you should carefully and delicately disassemble then in lead casings. much of the extra "thousands" in cost are spent in proper protective casings, which was the real reason for Intel to do away with the Socket interfaces for Slot 1 in the first place. New high performance ceranics and Lead-magnesium alloys have allowed the protective casings to shrink again, but you still need to be careful. And dont EVER let two Intel cores come in contact with each other, or not even the Liquid Hydrogen active cooling system will save you...
Dammit! I should have posted anonymously! Now they'll get me! It's a good thing I'm posting from OpenBSD virtualized inside of Tinfoil Hat Linux! I can use the HyperThreading Hyperspace technology to encrypt my essence and escape! Fight the Future.
***Disclaimer*** Fluoride is good for your teeth and bones. Fluorosis is nothing but a commie... er, a Terrorist plot. If you don't ingest fuoride and develop fluorosis then the terrorists will have won! Make sure you brush your teeth with an ADA approved sodium-flouride "activated" toothpaste, and be only drink potassium-fluoride supplimented water. Ignore naturally occuring "healthy" calcium-fluoride that only hippies and tree-huggers advocate!
buildworld is compilation. that might imply that development can benefit significantly, whether on Unix or Windows NT. How about the inverse... do you find that servers running on (I'll assume you run) BSD perform better with SMP then they would under Uniprocessor systems?
If all you serve is static webpages under a linear Apache, then I doubt it. If you run CGI, or possible development versions of apache (it looks like they might be working on threading it) you will likely see performance.
When it comes to Windows, IMO preffered for desktop/workstation use over Serving anyday, a significant advantage may come in improved responsiveness when the GUI environment doesn't have to compete with other system components. This is most obvious even under a single CPU running BeOS, but an SMP Win2K would likely behave similarly smooth. Hopefully X11 environments running on FreeBSD and Linux (Which by and large really need all the help they can get here) can also gain significant responsiveness. Even if the Window Manager/Environment aren't multithreaded, at least they won't have to compete with every other daemon and service on the system.
Perhaps the parent could be considered offtopic. I would argue that this post is almost worthy of its own submission, and in that respect could have earned at least a +2 interesting. In relation to the thread it augments, it seems to be a witty commentary on the effects of misinformation not just in computing systems, but in the much wider fields of computer science in relation to existential philosophy. In this aspect, this post may have been worthy of +2 or +3 insightful. Maybe even +1 funny for the sarcastic delivery.
I am posting under this message in solidarity, but I regret that the AC didn't use a name in this instance. It would have been less vulnerable to mistreatment by a moderator not worthy of their points. Since this post will not likely reached a well deserved +4 before being archived, I will reprint this simply elegant statement below.
Thoughtless moderation helps nobody, and weakens the community. Rather than waste your moderator points, you should have saved them for a more thoughtful moderator to use. Now for some delicious irony, I fully expect to be modded down both -1 redundant and -1 offtopic.
cheers.
Re:Finally! (indeed) (Score:-1) by Anonymous Coward on Wednesday February 20, @05:53PM (#3040304)
Yes, just think about how much more quickly intelligent agents can be developed using genetic algorythms in a scenario with a tricky god.
It seems the compund word you seek would by "HypoThreading", as opposed to HyperThreading. This might not be as facetious as you intended, as there are come approached to clustering or compute serving that might be considered an implementation of this hypothreading.
I can't recall off-hand how IBM handles this, but Linux doesn't support quite as many CPUs as does, say, IRIX. So the current solution seems to be to partition a large system into multiple smaller systems. Maybe it would be feasible to virtualize some form of Hypothreading to allow one system partition to utilize an entire enterprise class system.
Then again, since this is a gross "hypersimplification", I think not.
Despite VmWare, The Intel architecture isn't really virtualized. I am willing to believe that IBM can actually put multiple CPU cores on one die, for many SMP benefits without the downside of requiring multiple CPU dies and infrastructure.
On the other hand, for Intel this seems to be unrelated, and a cheap hack, where the CPU presents an SMP interface to the OS only to to request multithreaded code. Requesting multithreaded code should be possible without sending misinformation to the basic Operating System services. This seems to be a symptom of the disconnect inherent in having different companies producing the Architecture and the Operating System. It seems unlikely that you would see such a crude hack for fundamental systems infrastructure coming from an integrated vendor such as SGI, Sun, or even Apple. The Mips and PPC/Power don't lie about such things, because the support chipsets are actually supported by the Operating Systems.
Really, this seems reminicent of C/H/S mangling in storage interfaces and long file name mangling in the vFat filesystem. While is has taken up many generations (in computer years) to abstract the state of the art from such persistent kludges, they still haunt the consumer computing space to this day. Now do we really need to go even further backwards fuck with how the CPU interfaces with the core system?
Of course, perhaps I am not giving the Wintel juggernaut the benefit of the doubt... after all, they will have to bear the consequenses of such a choice, so maybe they aren't just adding saddlebags to the most basic part of the computing system. Perhaps they have the foresight to resolve this in the next few years before making this burdensome interface an accepted standard. It would be shameful too add more standardized interface limitations... such as the standardized "Gates" hopping of the 640K limit on commodity computing harware, or the IDE limit of 540MB, no 2GB, no 8GB, no 36GB, no wait 140Gb, Ad Nauseam. All of these arbitrary limitations were the results of cutting corners and not sending fully honest information to basic system interfaces. Can't the OS send efficient multithreaded code for processing without living a lie?
Win2K Pro allows 1-2 processors. If you need 4 processor, Then you Need Windows 2000 Server. 8 requires Advances server. I think that Datacenter can allow up to 16 processors in theory. Enabling hyperThreading seems to mean "lying to Windows" as a cheap hack to enable multithreading on a non-SMP machine. I doubt this induces processor-hotes schitzophrenia (rather, multiple personality disorder).
If the article they specifically stated that a dual processor machine will run on Windows 2000 Professional without problems. The hardware can tell Windows that it has double processors, but this does not give you the effect of 4 virtual CPUs with 2 CPUs. This is only a cheap hack to compensate for prior assumptions in computing - namely, that a single CPU will have reduced performance with multithreaded code. This is because a context switch for each thread can waste time, making multithreaded code seem expensive. Even on Intel hardware, the BeOS had fairly cheap context switches, and the exceptional performance on even single CPU systems anecdotally disproved some generally accepted notions on the impact of multithreaded code.
In this article, benchmarks seemed to indicate that while single CPUs with HyperThreading enabled slightly outperformed those with disabled HT, the dual-proc systems tended to lose with HT enabled. This could jibe with the above when you consider that a single CPU with Hyperthreading really isn't 2 virtual CPUs. Rather, by masquerading as 2 CPUs to Windows, Windows will send code that is multithreaded, which can be more efficient with an effective scheduler. On the other hand, with 2 CPUs, there is no advantage in telling Windows you have 4 CPUs, because either way you are getting multithreaded code. Thus, the negative consequences based on the hack (lie) are no longer compensated by threaded code outperforming nonthreaded code. Note that all of this assumes that there is No Real Change in the hardware funtionality when enabling Hyperthreading, other than the CPU requesting multithreaded code. It would have been interesting to see a screenshot of the CPU load monitor with a non-idle task load to see how the load delta is presented on the 2 "virtual" CPUs belonging to each real CPU.
Perhaps this will allow Windows to approach responsiveness approaching that of BeOS even on single CPU systems, although dual-procs will always be better for abstracting interface performance from system load.
Overheating looks like a valid concern in this case. While overclocking will push the limits of heat dissipation, that is not the same as heavy use. An overclocked processor will still generate significant heat even when in an idle loop.
The issue that concerns me is that most consumer CPUs aren't designed with true heavy use in mind, and the specs usually consider that most of the time, the standard processor is not pegged. This can be an issue if full time compute processes don't give the processor time to idle, as in Seti or Distributed.Net usage. That is why these projects specifically warn against overclocking - the combination adds up.
Now even with a full time load, like with the Distributed.net client, the entire processor die isn't generating heat - some of the CPU logic remains idle. This still allows for a buffer for heat dissipation, as slight as it might be. Now with this hyperthreading technique, most of the die can be actively generating heat simultaneously, pushing the heat generation potential higher than the specs likely considered.
Considering that the largest problem that all Intel processors had since the Pentium 60 involves inability to deal with sufficient heat dissipation, this concerns me deeply. I fear the day soon approached where the Intel processor code names are based on the Black Body Effect: The low end "black" "dull red" and "infra-red" models are outmatched by the "Hot-white" and "blue blaze" series, but much of the extraordinary cost is attributed to maintaining active-cooling systems that are spontaneous-combustion-retardant.
And the Melting point of silicon substrate with varioius doping agents will soon become common knowledge.
Well, Be became free... many went to download the "Free BeOS" download. Now, from the ashes, emerges a BSD style Open Source "OpenBeOS."
NeXT there needs to be an effort to port OpenBeOS back to the PPC, Hobbit, and a handfull of bastardized/orphan architectures (Alpha, HPPA, ARM...). Call this "NetBeOS" and the Cosmic order will be restored once again.
Then to recompense for past commercial transgressions, let it be the great desktop MS killer. Perhaps then all will be well as disgusting jeers of the Slashdot community will greet the demise of Windows, with the balance of reformed trolls cheering "Let it BE!"
-castlan ...having those funny slashdot dreams again...
Be failed on the Mac platform? Apple shut Be out of their platform, so that none of the G3 Macs could run it. Be's failure on Apple is comparable to Netscapes failure on Windows 98, except that Netscape's product was free, and had legal defense against _blatant_ antagonism (as when MS temporarily broke Netscape browser support).
Lack of apps is a weak argument, unless you meant "Lack of apps by my favorite Mac/Windows software company." A glut of Windows apps doesn't mean that they are all necessary or even useful. In contrast, every commercial BeOS app I used was very high quality, and there was an abundance of genuinely useful freeware as well. BeOS was viable for just about any task the average user performs, and it excelled in some less common tasks. While MS Office wasn't available, There were substitute applications availale that could perform the tasks. Word processing was enhaced by the extensive metadata, so that a fancily formatted document could seamlessly be used by a raw text editor. While the bundled NetPositive was a rather basic browser, it was undisputably superior to the original Internet Explorer. Lack of Java was a definite negative, but more often an inconvienience than a showstopper. In contrast, it was faster, simpler and more robust than Windows Web Browsers. Opera was available if you needed heavy duty web browsing. An email client was included, many commercial clients were available. GNU utilities were available, as was a GUI development environment and no-brainer GUI controlled network services. As for the Mac, SheepShaver was available which hosted a virtal Mac environment inside the BeOS on PPC hardware, so even irreplaceable Mac software wasn't a barrier. Less refined emulation was available for DOS/Windows environments, but the "Lack of apps" charge is easily laid to rest when you consider the body of Free GNU/Linux software that wasn't much further than a recompile away.
As for the failure on PC hardware, sufficient reasons should be evident from browsing only comments scoring 4 and above on this story.
You make a very good point. But BeOS wasn't first a PPC thingy - It originally ran on the Hobbit processor, primarily because they were so cheap. Then the PPC 603 was available, very powerful considering how cheap it was, so they used that for their BeBox. Even though the 604 was more of a workstation CPU, and designed with SMP in mind, Be just haced up a reasonable 603 SMP setup. The idea was that 1x200 MHz processor was more epensive than 4x66 MHz or 2x133 MHz. Writing their streamlined multithreaded OS with this in mind, they could wring more performance out of cheaper hardware.
As much as this appealed the the hacker-geek, it turned out that a bit more work to get to Mac PPC 60x line was more cost effective, especially with the low end macs finally leveraging commodity components. Mac IDE was a reality, and becoming cheaper than a snazzy custom box woth a small target market (the intersection between hardware hackers and content creators).
Apple was very friendly at this time, and helped significantly with porting BeOS to Macs, which wasn't much different than the effort already underway to commoditize Apple hardware by allowing clones. This gamble was based on the increasing success of Windows PCs edging Apple out of their previous markets.
The fascism and xenophobic behaivor from Apple started after Jobs was brought on board, killing the clone program and closing off the software. And what the hell happened to MkLinux after that? Unfortunately those 3 interests of mine were slashed in one fell swoop, and The Bastard Jobs even (mass) sent me an insulting letter about how I would have just bought an Apple anyway if if weren't for (the innovative and cost-effective) Power Computing stealing 99% of their sales.
As much as I hated it, Apple never quite realized its (Gil Amelio's?) goal of becoming an open hardware platform, so Apple had every right to shut them out of their hardware. On the other hand, Intel actually supported Be pretty heavily at that time, which is why the focus at Be changed to Intel platforms, compatible with but AFAIK not optimizing for AMD processors.
Microsoft has no legit claims on x86, other than it was the most popular platform, and by nature of being the Monopoly they were entitled to shut out competeors with heavy handed tactics.
In summary, Apple hurt Be at least as much as Microsoft, but Apple didn't violate anybodys rights in doing so.
-castlan
p.s. You have a point with the last bit too... Microsoft exchanged some beads with the creator of Quick and Dirty DOS (Seattle Softworks maybe) to gain the significant start of their empire, New York. This was a significant force in breaking the occupation by of IBM/England. Compaq was Philadelphia. And this nonsence was written by somebody who is delerious and in severe need of sleep.
As far as Free Unices on SGI, the Indy is currently the best supported. It is the only SGI MIPS machine currently capable of running XFree under Linux. NetBSD has a bit more success then Linux, but there it also seems that the Indy is among the best supported. If you have An O2, NetBSD might be your only choice. OpenBSD doesn't yet have anything to show, but it will probably have similar support to NetBSD when it finally appears.
As for Gnu/Linux, Debian is usually the best bet with diverse, uncommon hardware, including the SGI Indy. You can also find information off of SGI's Open Source and Linux site, and even Red Hat flavored stuff here and there.
The "News" seemed to be that Debian supports obscure and older hardware - the afterthought "with Debian" was relevant for you. While this specific example was old AXPs that can be had for minimal cost, you could have inferred that Debian might also have support for MIPS... which it does. While Debian/BSD still hasn't come into its own yet, you might find that NetBSD can be more stable than Linux in the meantime. But your Indy has choices beyond 5.3+XFS and 6.(0,2,3,5). Have you looked into Windows NT 4.0?
All G4s have graphics acceleration hardware. Just because they have that capability, doesn't mean that they are using it. The software has to support the graphics acceleration before it will provide any benefit. Once it is properly supported, and graphics performance isn't strictly CPU bound, Mac OS X will prove more useable on lesser machines.
Hey, It was off the top of my head and I was mistaken. I'm surprised that it took the Alien maintainer to notice my bubble, and frankly a little pleased too. It is heartening to see that a prolific Debian developer like yourself is still responsive in public forums. Congratulations on helping Debian remain my preferred distro.
-castlan
p.s.
Have you considered adding functionality to Alien to support Open Packages? It looks like it hasn't make much progress recently, but I am still optimistic regarding its future. Some names I recognize from Progeny also seem to be significantly involved, and it seems like a worthy project. What do you think of its viability considering the FHS?
There is a subtle difference you might not realise. For Debian, the "later toys" are all that are added in newer releases. If you consider that bugs fixed in newer releases can be outweighed by bugs added with newer features, then you might see that there is a better way to fix bugs. When bugs in package foo3.2, the answer isn't to upgrade to foo3.3 - debian backports the fixes, resulting in foo3.2-x, where x is incremented for each new bugfixing release.
The upshot is that you cant compare a package's bugs by looking at the Debian version - that is what the changelog is for. The Debian version only indicates additional new features. If the package foo3.3 adds a new feature (toy) that you actually need, then foo3.2-x won't be sufficient. Debian doesn't just backport security fixes, bug fixes are backported too - but usually the emphasis is just on "important" major bugs, which includes security fixes.
To reciprocate, Red Hat has made significant improvements to their security with their new empasis on servers over desktops. In my experience, I still find that Red Hat is not yet comparable to Debian Stable for server security. Perhaps if the trend of profitability and server emphasis continues, then the advantages of commercial support will prevail and Red Hat will prove superior WRT security.
this post shouldn't be +5 insightful. It should be a link off of the debian Homepage.
Maybe not, but it should at least be under the About link, or in an advocacy page. The salient point is that Debian, as an open organization, is fundamentally differnet than currency modulated corporations that release Linux. If somebody decides to spend 8 hours a day, 2 days a week working on FreeCiv for Debian, there is no resulting negative impact to the core packages such as Apt. A bug in Apt-get is orthoganal to work done on "extra" by hobbyists who don't take resources away from core maintainers.
As stated, bugs in the base system held up release. Bugs in 6 kazillion non-core packages are irrelevant to release.
Did you even bother to click on the link so kindly provided in the previous post? It looks like you barely comprehended what Shiny said at all. Debian Stable is comparable to that of OpenBSD releases. You state that comparing the two is daft, after complaining about "a year and a half" of security updates. Or you could realise that perhaps the code has been audited for a year and a half.
The OpenBSD security audit, and all security audits, need to be performed on a stable code base. If you use new and untested code, then all of that auditing had been defeated. The OpenBSD audit only takes place on the "core" of OpenBSD, which means that you open yourself to insecurity if you activate the "ports" and other software which isn't considered part of OpenBSD proper - hence the claim of no remote explaits in the "Default install".
As for Debian, the security does not restrict itself to any "core" of packages - all included Free Software is valid, and their exploits "count". In spite of this, Shiny's link would have told you that in 2001, Debian GNU/Linux only had 1 remote exploit compared to OpenBSD's 7 remote exploits. So if you are planning on running Ports not included in OpenBSD core, Debian Stable arguably has better resistance to "remote holes".
This year and a half of debian auditing is evidently effective, contrary to your statement that "Debian has comparable security problems to any other" Linux distro. The same Security Focus report for 2001 claims that Debian Gnu/Linux had 14 total vulnerabilities, compared to Mandrakes 29 and Redhat's 40. "Sweetheart", you should realise that Debian Unstable is only "unstable" compared to Debian Stable. In Practice, I find that Debian Unstable is comparable to a Redhat x.0 release, Testing is comparable to most Redhat.x releases later than 0 (e.g. 7.3) and Debian Stable is comparable to an OpenBSD Release.
When you say up to date, do you mean the distribution installed on your system, or the CDROM/ISO? Rather than reinstalling each new version with a CD, it is much simpler and to seamlessly upgrade your system with one command, and you don't need to wait 6 months for a new release to do it. You can do upgrade daily if you wish. It seems a little silly to wait for CDs to be pressed and distributed, or even to download entire 650 Megabyte ISOs when you can download only the individul files that changed, saving time and bandwidth.
You can think what you want, but it might make sense to consider that the "testing" distribution style is still pretty new, this upcoming release will be the first to utilize it. After that, I really do except that feature realeases will occur more frequently. Of course, that will have little effect on current Debian users with net connections, who always had the option of tracking more current releases if stability wasn't their top priority.
The last time I did a comparison, OpenBSD and Debian were neck and neck, though I theorized that it looked like Debian would fall behind by the Next release of OpenBSD. OpenBSD releases every 6 months, December and June, disregarding subjective milestones. That is, 3.0 just meant that it was the release after 2.9. Regardless, I was wrong, Debian has kept up, even if the releases aren't as consistently timed. OpenBSD released 3.0 on December 1, 2001, OpenBSD 2.9 released June 1, 2001, and so on. Debian released 2.2r5 on January 10, 2002. 2.2r4, was released on November 5, 2001. 2.2r3, was released on April 17, 2001. 2.2r2, was released on December 3, 2000. To me, they both seem to maintain about 2 releases per year.
Of course, Debian is very conservative, issuing only bug fixes and security patches, and strictly limiting new development for each new major relaseWoody. OpenBSD releases are also stable compared to Debian, but the development isn't segregated from the bug-fixes via Feature-freezes with Major/Minor releases as in Debian. Off the top of my head, OpenBSD had some significant changes, including XFree86 4.1 and PF replacing IPF.
You say that by the time releases come out, software packages are out of date. I have to challenge that - cutting edge packages are by definition not stable, and a package being "out of date" doesn't mean that it is obsolete just because a newer version exists. Bugfixes are not a valid excuse to upgrade to the latest version of a software release, as you may add just as many bugs as you fix. The Right Way is to backport fixes, which Debian does on a regular basis. Additional features are only significant if you find them useful, they don't make your current version any less useful. If you find that you need features added in a newer version, then it is trivial to apt-get update leetproggie.
If you think that rolling your own version of a package is preferable to a guaranteed working version, that means that you shouldn't be using a distribution: you should be grabbing your own.TGZs and building your own cutting edge system.
As it was already established that you shouldn't be relying on a stable distro but rolling your own system, you shouldn't need to rely on an installer. Just extract your Linux filesytem from a tarball and be done with it. You can roll your own options, so why do you need an installer to walk you through it? If you are as leet as you imply, the Debian installer is ideal... it allows you to use the shell to complete as many steps as you wish, and will take over from where you left it when you start to trip over your own feet. What is so awful about the Debian installer? It isn't a WIMP GUI? What are some of these "many bugs, etc."?
If you really need a WIMP (Windowing Interface, Mouse Pointer) then you should look into Progeny Debian, which made a good installer (read: point and click) which leverages the packages. The same GUI installer is reused for later reconfiguration of the system as well. Unfortunately, Progeny no longer sells their GUI improved version of Debian (Newton release, a meld of Potato and Woody) but you can can still find an ISO if you would like to try it. If you become comfortable with the Debian CLI subsystem, you can always point/etc/apt/sources.list towards the Debian archive to upgrade to Woody.
As for your personification, you should at least qualify Debian as having High Functioning Autism, or perhaps Asperger's Syndrome. But the prognosis is very good, as Debian has an excellent support community. And that obsessive mind works quite well with clearly defined rules, which makes the Debian Policy Manual quite a boon with the thoroughly defined package dependancies superior to competing operating systems.
It seems that you misunderstand - Alien works great, it makes RPMs, DPKGs, and TGZs interchangeable. Your problem comes from the fact that Redhat RPMs (like Debian DPKGs and Slackware TGZs) also contain control information, effectively shell scripts that rely on the filesystem of the intended distribution. Since Redhat and Debian (all releases) use differnt locations for e.g. their rc.X files (initscripts), the control information isn't portable.
The Linux Standards Base is a fairly useful effort, but it includes the Linux Filesystem Hierarchy Standard, which seems to be what you intended to take Debain to task for. AFAIK, the RPM standard is specified only in the FHS, and not directly in the LSB. So you meant "Debian supports the FHS via alien..."
The FHS is full of good intentions, but unfortunately the reality falls far short. DJB has a number of valid criticisms that are as of yet not addressed by the LSB, or more accurately, the FHS. While I tend to think that standards are a good thing, I don't think that you should ignore convention in favor of provably flawed standards, so the FHS is not as desireable as I once felt. Without regard to the benefit of the FHS, I will argue that Debian supports it, in fact the Debian Project has made FHS support a specific requirement in their official policy manual.
The part of the FHS that you seem to be missing, is that while RPM is the official packaging format of the FHS, that doesn't mean that Redhat is automatically compliant. Rather, the standard RPM format is that defined in the publication Maximum RPM, and Redhat has continues development of their RPM format since that time. That means that the average RPM distributed with Redhat is not FHS compliant. Offical standard RPMs are handled by Debian via Alien flawlessly, and likely by Redhat and SuSE as well.
More importantly, the "Maximum RPM" RPM format isn't the most important feature of the FHS. More important is adherence to the recommendations of where in the directory tree different types of files should be. It seems that Debian is the most compliant distro, closely followed by SuSE last time I saw a comparison. You may have noticed when you administered the Debian Boxen that the/opt directory was completely unsed by Debian, and AFAIK has always been that way. Since the release of Potato, something as laborious as moving every single changelog, readme, info page, man page and other textual file from its previous location (usuallt/usr/doc) into the FHS mandated/usr/share/doc hierarchy. This was of dubious benefit at best, other than strict adherence to the FHS.
Just a small point of contention, every "Linux distribution" can arguably be called a distinct OS -- Unless you support that they are all just implementations of the GNU OS. But NetBSD and FreeBSD are just distributions of 386BSD. OpenBSD is just another version of NetBSD. AIX and IRIX are just distributions of UNIX. Even if all Linux distros are unified by the LSB, that's not much different than how all Unices have been unified by the POSIX standard. And Remember, Debian keeps their own Linux tree, as does Redhat, both distinct from the Official Linux at Kernel.org.
Theoretically, software developers should only have to release their files as.TGZ archives, and Free Software Operating systems should respect the conventions... especially in the common case where the software project existed longer than the OS in question. For the most part, the Free Software BSDs have done this. FreeBSD developed their Ports system allowing them to keep a tree of makefiles which would aid in compilation of software packages that isn't part of the standard system. The exception is that the BSDs tend to have integrated XFree86 into their "base system", so they have modified XFree86 from the standard distribution. Debian has gone much further than this, packaging almost any Free Software of interest, for inclusion into their system... making Debian the largest, most versatile system to date.
As a Red Hat user, it it is unfortunate but understandable that you didn't know more about the FHS and APT when you administered the Debian boxen. Perhaps you would have realised that you were likely using a non standard RedHat 7.x (e.g.) specific RPM. Even Mandrake, which directly descended from Redhat, has enough of a delta from Redhat that not all RPMs will interchange between the two. RPMs intended for other distros will tend to fare much worse. Even an RPM for Redhat 6.0 isn't recommended for Redhat 7.3, so it was a bit naive to expect a non-FHS RPM to work. Better would have been to type:
apt-cache search pppoe
If you wanted to install Roaring Penguin's PPPoE RPM to see it it was available, and what the APT package is named. If you had an RPM that you needed to install, then odds are that it was available. Then you type:
apt-get install pppoe
and all would have been well. Even if you had the FHS compliant rp-pppoe.RPM, using the APT/.dpkg version would be preferred, as the DPKG format has superior dependancy handling.
I am heartened to see that you haven't been down modded, I I hope that my post has been informative.
Slashdot Mirror
I have yet to use any PVR services, but from what I understand they can make recommendations of shows that you are likely to enjoy based on your viewing habits. I am not sure if you can opt out for privacy reasons. But a better alternative to stagnation might be to turn the TV off now and then.
-castlan
Just a nit I have to pick, but 802.2 Ethernet is not a broadband medium. Cable is broadband, because you have "channels". A school that only has ethernet connectivity would be said to provide baseband connectivity.
-castlan
hotgrits.slashdot.org
For when "releasing Woody" doesn't involve Debian.
Where else will you find geek eroticism?
Well, I guess there is always the Lesbian Linux distro.
Before the shame sets in, lemme add
petrified.slashdot.org for pinups
allyourbase.slashdot.org for wars, terrorism, political revolution.
there, that last one made me feel a bit less dirty. 'Cuz violence is always more acceptable than sex (in post-puritan USA!)
-castlan
Just be glad you're not an Apple fringe (clone supporting), Windows Using, GNU advocating, C=64 loving BeOS bigot. Even if I secured the funds for a New Macintosh, I'd only be slightly sated, resentful of Chairman Jobs, and wistful for OpenBeOS' unveiling.
In the meantime, I'm slashdotting on Win2k, short on 72pin true Parity for my TurboSlab Color (Which isn't supported by Linux, or even NetBSD!) and still trying to get Darwin going on my PowerCenter Mac clone. (Why PowerTower, but not PowerCenter!)
-castlan
I'd have to argue against the "sex appeal" arguement. Doesn't Be Inc. have a claim of Prior Art, in light of how often the BeOS made Jean Louis Gassee's nipples hard?
Just a bit of enlightenment.... which reminds me, wouldn't Enlightenment also have a claim to prior art?
-castlan
mmm, pretty mac ghetto....
You have a point. Most people don't know it, but modern processors use a hazardous combination of Potassium Fluoride and spent Plutonium to regulate clock speed, which is the real reason that it isn't safe to overclock your computer!
That density is especially thick with server CPUs, especially the Xeon. That is why, to date, nobody has set off large enough of a reaction to be deadly with overclocking PCs, but that is not the case with Xeons, whose Plutonium content is dangerously close to the Critical Mass. And you thought your Intel CPU ran hot! Everybody who runs Xeon servers knows better than to play with the clock speed.
In fact, that is why you can't ususally buy Xeons without ECC RAM, the radiation put off by the computation would too readily disrupt the memory state information. What, you bought that nonsense about solar flares or other sources of random radiation causing bit decay? Of, and FYI, don't run Distributed.net or Seti@home on your Xeon if you have fillings or a mercury thermometer in the area, unless you are interested in a direct demonstrations of fusion in action.
Really, since the Cold war had ended, Microprocessors have been constantly dropping in price. Why was this phenomenon never observerved until the 80? Moore's Law my ass, how about "military surplus in action." It is much too expensive to store all of this spent plutonium in federal compunds. So the FCC had to ensure that computers had sufficient shielding, and now, there you go. Let me reiterate that ever since the "Pentium Pro" (Plutonium Recycling Operation) and with each new generation of CPU, active cooling remains a matter of utmost priority.
Really, they would have just put it in the drinking water supplies to distribute the threat amongst all of our nations' citizens (like taxes and fluoride) except that in secret military tests they found that the subjects teeth and bones started to glow in the dark, which would have been too obvious to cover up for long. So they stationed the subjects in parts of Japan, Las Vegas, and tropical locations so that the glowing would be concealed by all of the Neon Lights and overpowering sun (causing a sun tan, to help cover the light emissions) and classisifed the research.
Well, in any case, I highly recommend tht you don't ever "crack" one of the more recent Xeons apart. Rather, you should carefully and delicately disassemble then in lead casings. much of the extra "thousands" in cost are spent in proper protective casings, which was the real reason for Intel to do away with the Socket interfaces for Slot 1 in the first place. New high performance ceranics and Lead-magnesium alloys have allowed the protective casings to shrink again, but you still need to be careful. And dont EVER let two Intel cores come in contact with each other, or not even the Liquid Hydrogen active cooling system will save you...
Dammit! I should have posted anonymously! Now they'll get me! It's a good thing I'm posting from OpenBSD virtualized inside of Tinfoil Hat Linux! I can use the HyperThreading Hyperspace technology to encrypt my essence and escape! Fight the Future.
***Disclaimer***
Fluoride is good for your teeth and bones. Fluorosis is nothing but a commie... er, a Terrorist plot. If you don't ingest fuoride and develop fluorosis then the terrorists will have won! Make sure you brush your teeth with an ADA approved sodium-flouride "activated" toothpaste, and be only drink potassium-fluoride supplimented water. Ignore naturally occuring "healthy" calcium-fluoride that only hippies and tree-huggers advocate!
buildworld is compilation. that might imply that development can benefit significantly, whether on Unix or Windows NT. How about the inverse... do you find that servers running on (I'll assume you run) BSD perform better with SMP then they would under Uniprocessor systems?
If all you serve is static webpages under a linear Apache, then I doubt it. If you run CGI, or possible development versions of apache (it looks like they might be working on threading it) you will likely see performance.
When it comes to Windows, IMO preffered for desktop/workstation use over Serving anyday, a significant advantage may come in improved responsiveness when the GUI environment doesn't have to compete with other system components. This is most obvious even under a single CPU running BeOS, but an SMP Win2K would likely behave similarly smooth. Hopefully X11 environments running on FreeBSD and Linux (Which by and large really need all the help they can get here) can also gain significant responsiveness. Even if the Window Manager/Environment aren't multithreaded, at least they won't have to compete with every other daemon and service on the system.
-castlan
I am posting under this message in solidarity, but I regret that the AC didn't use a name in this instance. It would have been less vulnerable to mistreatment by a moderator not worthy of their points. Since this post will not likely reached a well deserved +4 before being archived, I will reprint this simply elegant statement below.
Thoughtless moderation helps nobody, and weakens the community. Rather than waste your moderator points, you should have saved them for a more thoughtful moderator to use. Now for some delicious irony, I fully expect to be modded down both -1 redundant and -1 offtopic.
cheers.
Re:Finally! (indeed) (Score:-1)
by Anonymous Coward on Wednesday February 20, @05:53PM (#3040304)
It seems the compund word you seek would by "HypoThreading", as opposed to HyperThreading. This might not be as facetious as you intended, as there are come approached to clustering or compute serving that might be considered an implementation of this hypothreading.
I can't recall off-hand how IBM handles this, but Linux doesn't support quite as many CPUs as does, say, IRIX. So the current solution seems to be to partition a large system into multiple smaller systems. Maybe it would be feasible to virtualize some form of Hypothreading to allow one system partition to utilize an entire enterprise class system.
Then again, since this is a gross "hypersimplification", I think not.
-castlan
Despite VmWare, The Intel architecture isn't really virtualized. I am willing to believe that IBM can actually put multiple CPU cores on one die, for many SMP benefits without the downside of requiring multiple CPU dies and infrastructure.
On the other hand, for Intel this seems to be unrelated, and a cheap hack, where the CPU presents an SMP interface to the OS only to to request multithreaded code. Requesting multithreaded code should be possible without sending misinformation to the basic Operating System services. This seems to be a symptom of the disconnect inherent in having different companies producing the Architecture and the Operating System. It seems unlikely that you would see such a crude hack for fundamental systems infrastructure coming from an integrated vendor such as SGI, Sun, or even Apple. The Mips and PPC/Power don't lie about such things, because the support chipsets are actually supported by the Operating Systems.
Really, this seems reminicent of C/H/S mangling in storage interfaces and long file name mangling in the vFat filesystem. While is has taken up many generations (in computer years) to abstract the state of the art from such persistent kludges, they still haunt the consumer computing space to this day. Now do we really need to go even further backwards fuck with how the CPU interfaces with the core system?
Of course, perhaps I am not giving the Wintel juggernaut the benefit of the doubt... after all, they will have to bear the consequenses of such a choice, so maybe they aren't just adding saddlebags to the most basic part of the computing system. Perhaps they have the foresight to resolve this in the next few years before making this burdensome interface an accepted standard. It would be shameful too add more standardized interface limitations... such as the standardized "Gates" hopping of the 640K limit on commodity computing harware, or the IDE limit of 540MB, no 2GB, no 8GB, no 36GB, no wait 140Gb, Ad Nauseam. All of these arbitrary limitations were the results of cutting corners and not sending fully honest information to basic system interfaces. Can't the OS send efficient multithreaded code for processing without living a lie?
-castlan
Win2K Pro allows 1-2 processors. If you need 4 processor, Then you Need Windows 2000 Server. 8 requires Advances server. I think that Datacenter can allow up to 16 processors in theory. Enabling hyperThreading seems to mean "lying to Windows" as a cheap hack to enable multithreading on a non-SMP machine. I doubt this induces processor-hotes schitzophrenia (rather, multiple personality disorder).
If the article they specifically stated that a dual processor machine will run on Windows 2000 Professional without problems. The hardware can tell Windows that it has double processors, but this does not give you the effect of 4 virtual CPUs with 2 CPUs. This is only a cheap hack to compensate for prior assumptions in computing - namely, that a single CPU will have reduced performance with multithreaded code. This is because a context switch for each thread can waste time, making multithreaded code seem expensive. Even on Intel hardware, the BeOS had fairly cheap context switches, and the exceptional performance on even single CPU systems anecdotally disproved some generally accepted notions on the impact of multithreaded code.
In this article, benchmarks seemed to indicate that while single CPUs with HyperThreading enabled slightly outperformed those with disabled HT, the dual-proc systems tended to lose with HT enabled. This could jibe with the above when you consider that a single CPU with Hyperthreading really isn't 2 virtual CPUs. Rather, by masquerading as 2 CPUs to Windows, Windows will send code that is multithreaded, which can be more efficient with an effective scheduler. On the other hand, with 2 CPUs, there is no advantage in telling Windows you have 4 CPUs, because either way you are getting multithreaded code. Thus, the negative consequences based on the hack (lie) are no longer compensated by threaded code outperforming nonthreaded code.
Note that all of this assumes that there is No Real Change in the hardware funtionality when enabling Hyperthreading, other than the CPU requesting multithreaded code. It would have been interesting to see a screenshot of the CPU load monitor with a non-idle task load to see how the load delta is presented on the 2 "virtual" CPUs belonging to each real CPU.
Perhaps this will allow Windows to approach responsiveness approaching that of BeOS even on single CPU systems, although dual-procs will always be better for abstracting interface performance from system load.
Overheating looks like a valid concern in this case. While overclocking will push the limits of heat dissipation, that is not the same as heavy use. An overclocked processor will still generate significant heat even when in an idle loop.
The issue that concerns me is that most consumer CPUs aren't designed with true heavy use in mind, and the specs usually consider that most of the time, the standard processor is not pegged. This can be an issue if full time compute processes don't give the processor time to idle, as in Seti or Distributed.Net usage. That is why these projects specifically warn against overclocking - the combination adds up.
Now even with a full time load, like with the Distributed.net client, the entire processor die isn't generating heat - some of the CPU logic remains idle. This still allows for a buffer for heat dissipation, as slight as it might be. Now with this hyperthreading technique, most of the die can be actively generating heat simultaneously, pushing the heat generation potential higher than the specs likely considered.
Considering that the largest problem that all Intel processors had since the Pentium 60 involves inability to deal with sufficient heat dissipation, this concerns me deeply. I fear the day soon approached where the Intel processor code names are based on the Black Body Effect: The low end "black" "dull red" and "infra-red" models are outmatched by the "Hot-white" and "blue blaze" series, but much of the extraordinary cost is attributed to maintaining active-cooling systems that are spontaneous-combustion-retardant.
And the Melting point of silicon substrate with varioius doping agents will soon become common knowledge.
-castlan
Well, Be became free... many went to download the "Free BeOS" download.
Now, from the ashes, emerges a BSD style Open Source "OpenBeOS."
NeXT there needs to be an effort to port OpenBeOS back to the PPC, Hobbit, and a handfull of bastardized/orphan architectures (Alpha, HPPA, ARM...). Call this "NetBeOS" and the Cosmic order will be restored once again.
Then to recompense for past commercial transgressions, let it be the great desktop MS killer. Perhaps then all will be well as disgusting jeers of the Slashdot community will greet the demise of Windows, with the balance of reformed trolls cheering "Let it BE!"
-castlan
...having those funny slashdot dreams again...
Be failed on the Mac platform?
Apple shut Be out of their platform, so that none of the G3 Macs could run it. Be's failure on Apple is comparable to Netscapes failure on Windows 98, except that Netscape's product was free, and had legal defense against _blatant_ antagonism (as when MS temporarily broke Netscape browser support).
Lack of apps is a weak argument, unless you meant "Lack of apps by my favorite Mac/Windows software company." A glut of Windows apps doesn't mean that they are all necessary or even useful. In contrast, every commercial BeOS app I used was very high quality, and there was an abundance of genuinely useful freeware as well. BeOS was viable for just about any task the average user performs, and it excelled in some less common tasks. While MS Office wasn't available, There were substitute applications availale that could perform the tasks. Word processing was enhaced by the extensive metadata, so that a fancily formatted document could seamlessly be used by a raw text editor. While the bundled NetPositive was a rather basic browser, it was undisputably superior to the original Internet Explorer. Lack of Java was a definite negative, but more often an inconvienience than a showstopper. In contrast, it was faster, simpler and more robust than Windows Web Browsers. Opera was available if you needed heavy duty web browsing. An email client was included, many commercial clients were available. GNU utilities were available, as was a GUI development environment and no-brainer GUI controlled network services. As for the Mac, SheepShaver was available which hosted a virtal Mac environment inside the BeOS on PPC hardware, so even irreplaceable Mac software wasn't a barrier. Less refined emulation was available for DOS/Windows environments, but the "Lack of apps" charge is easily laid to rest when you consider the body of Free GNU/Linux software that wasn't much further than a recompile away.
As for the failure on PC hardware, sufficient reasons should be evident from browsing only comments scoring 4 and above on this story.
-castlan
You make a very good point.
But BeOS wasn't first a PPC thingy - It originally ran on the Hobbit processor, primarily because they were so cheap. Then the PPC 603 was available, very powerful considering how cheap it was, so they used that for their BeBox. Even though the 604 was more of a workstation CPU, and designed with SMP in mind, Be just haced up a reasonable 603 SMP setup. The idea was that 1x200 MHz processor was more epensive than 4x66 MHz or 2x133 MHz. Writing their streamlined multithreaded OS with this in mind, they could wring more performance out of cheaper hardware.
As much as this appealed the the hacker-geek, it turned out that a bit more work to get to Mac PPC 60x line was more cost effective, especially with the low end macs finally leveraging commodity components. Mac IDE was a reality, and becoming cheaper than a snazzy custom box woth a small target market (the intersection between hardware hackers and content creators).
Apple was very friendly at this time, and helped significantly with porting BeOS to Macs, which wasn't much different than the effort already underway to commoditize Apple hardware by allowing clones. This gamble was based on the increasing success of Windows PCs edging Apple out of their previous markets.
The fascism and xenophobic behaivor from Apple started after Jobs was brought on board, killing the clone program and closing off the software. And what the hell happened to MkLinux after that? Unfortunately those 3 interests of mine were slashed in one fell swoop, and The Bastard Jobs even (mass) sent me an insulting letter about how I would have just bought an Apple anyway if if weren't for (the innovative and cost-effective) Power Computing stealing 99% of their sales.
As much as I hated it, Apple never quite realized its (Gil Amelio's?) goal of becoming an open hardware platform, so Apple had every right to shut them out of their hardware. On the other hand, Intel actually supported Be pretty heavily at that time, which is why the focus at Be changed to Intel platforms, compatible with but AFAIK not optimizing for AMD processors.
Microsoft has no legit claims on x86, other than it was the most popular platform, and by nature of being the Monopoly they were entitled to shut out competeors with heavy handed tactics.
In summary, Apple hurt Be at least as much as Microsoft, but Apple didn't violate anybodys rights in doing so.
-castlan
p.s.
You have a point with the last bit too... Microsoft exchanged some beads with the creator of Quick and Dirty DOS (Seattle Softworks maybe) to gain the significant start of their empire, New York. This was a significant force in breaking the occupation by of IBM/England. Compaq was Philadelphia. And this nonsence was written by somebody who is delerious and in severe need of sleep.
As far as Free Unices on SGI, the Indy is currently the best supported. It is the only SGI MIPS machine currently capable of running XFree under Linux. NetBSD has a bit more success then Linux, but there it also seems that the Indy is among the best supported. If you have An O2, NetBSD might be your only choice. OpenBSD doesn't yet have anything to show, but it will probably have similar support to NetBSD when it finally appears.
As for Gnu/Linux, Debian is usually the best bet with diverse, uncommon hardware, including the SGI Indy. You can also find information off of SGI's Open Source and Linux site, and even Red Hat flavored stuff here and there.
The "News" seemed to be that Debian supports obscure and older hardware - the afterthought "with Debian" was relevant for you. While this specific example was old AXPs that can be had for minimal cost, you could have inferred that Debian might also have support for MIPS... which it does. While Debian/BSD still hasn't come into its own yet, you might find that NetBSD can be more stable than Linux in the meantime. But your Indy has choices beyond 5.3+XFS and 6.(0,2,3,5). Have you looked into Windows NT 4.0?
cheers
-castlan
All G4s have graphics acceleration hardware. Just because they have that capability, doesn't mean that they are using it. The software has to support the graphics acceleration before it will provide any benefit. Once it is properly supported, and graphics performance isn't strictly CPU bound, Mac OS X will prove more useable on lesser machines.
-castlan
Hey, It was off the top of my head and I was mistaken. I'm surprised that it took the Alien maintainer to notice my bubble, and frankly a little pleased too. It is heartening to see that a prolific Debian developer like yourself is still responsive in public forums. Congratulations on helping Debian remain my preferred distro.
-castlan
p.s.
Have you considered adding functionality to Alien to support Open Packages? It looks like it hasn't make much progress recently, but I am still optimistic regarding its future. Some names I recognize from Progeny also seem to be significantly involved, and it seems like a worthy project. What do you think of its viability considering the FHS?
There is a subtle difference you might not realise. For Debian, the "later toys" are all that are added in newer releases. If you consider that bugs fixed in newer releases can be outweighed by bugs added with newer features, then you might see that there is a better way to fix bugs. When bugs in package foo3.2, the answer isn't to upgrade to foo3.3 - debian backports the fixes, resulting in foo3.2-x, where x is incremented for each new bugfixing release.
The upshot is that you cant compare a package's bugs by looking at the Debian version - that is what the changelog is for. The Debian version only indicates additional new features. If the package foo3.3 adds a new feature (toy) that you actually need, then foo3.2-x won't be sufficient. Debian doesn't just backport security fixes, bug fixes are backported too - but usually the emphasis is just on "important" major bugs, which includes security fixes.
To reciprocate, Red Hat has made significant improvements to their security with their new empasis on servers over desktops. In my experience, I still find that Red Hat is not yet comparable to Debian Stable for server security. Perhaps if the trend of profitability and server emphasis continues, then the advantages of commercial support will prevail and Red Hat will prove superior WRT security.
-castlan
this post shouldn't be +5 insightful. It should be a link off of the debian Homepage.
Maybe not, but it should at least be under the About link, or in an advocacy page. The salient point is that Debian, as an open organization, is fundamentally differnet than currency modulated corporations that release Linux. If somebody decides to spend 8 hours a day, 2 days a week working on FreeCiv for Debian, there is no resulting negative impact to the core packages such as Apt. A bug in Apt-get is orthoganal to work done on "extra" by hobbyists who don't take resources away from core maintainers.
As stated, bugs in the base system held up release. Bugs in 6 kazillion non-core packages are irrelevant to release.
-castlan
Did you even bother to click on the link so kindly provided in the previous post? It looks like you barely comprehended what Shiny said at all. Debian Stable is comparable to that of OpenBSD releases. You state that comparing the two is daft, after complaining about "a year and a half" of security updates. Or you could realise that perhaps the code has been audited for a year and a half.
.x releases later than 0 (e.g. 7.3) and Debian Stable is comparable to an OpenBSD Release.
The OpenBSD security audit, and all security audits, need to be performed on a stable code base. If you use new and untested code, then all of that auditing had been defeated. The OpenBSD audit only takes place on the "core" of OpenBSD, which means that you open yourself to insecurity if you activate the "ports" and other software which isn't considered part of OpenBSD proper - hence the claim of no remote explaits in the "Default install".
As for Debian, the security does not restrict itself to any "core" of packages - all included Free Software is valid, and their exploits "count". In spite of this, Shiny's link would have told you that in 2001, Debian GNU/Linux only had 1 remote exploit compared to OpenBSD's 7 remote exploits. So if you are planning on running Ports not included in OpenBSD core, Debian Stable arguably has better resistance to "remote holes".
This year and a half of debian auditing is evidently effective, contrary to your statement that "Debian has comparable security problems to any other" Linux distro. The same Security Focus report for 2001 claims that Debian Gnu/Linux had 14 total vulnerabilities, compared to Mandrakes 29 and Redhat's 40. "Sweetheart", you should realise that Debian Unstable is only "unstable" compared to Debian Stable. In Practice, I find that Debian Unstable is comparable to a Redhat x.0 release, Testing is comparable to most Redhat
-castlan
Postgresql 7.1 is available, and will ship with Woody. 6.3.2 is also available for backwards compatibility.
Any other shortcomings to point out?
-castlan
When you say up to date, do you mean the distribution installed on your system, or the CDROM/ISO? Rather than reinstalling each new version with a CD, it is much simpler and to seamlessly upgrade your system with one command, and you don't need to wait 6 months for a new release to do it. You can do upgrade daily if you wish. It seems a little silly to wait for CDs to be pressed and distributed, or even to download entire 650 Megabyte ISOs when you can download only the individul files that changed, saving time and bandwidth.
You can think what you want, but it might make sense to consider that the "testing" distribution style is still pretty new, this upcoming release will be the first to utilize it. After that, I really do except that feature realeases will occur more frequently. Of course, that will have little effect on current Debian users with net connections, who always had the option of tracking more current releases if stability wasn't their top priority.
-castlan
The last time I did a comparison, OpenBSD and Debian were neck and neck, though I theorized that it looked like Debian would fall behind by the Next release of OpenBSD. OpenBSD releases every 6 months, December and June, disregarding subjective milestones. That is, 3.0 just meant that it was the release after 2.9. Regardless, I was wrong, Debian has kept up, even if the releases aren't as consistently timed. OpenBSD released 3.0 on December 1, 2001, OpenBSD 2.9 released June 1, 2001, and so on. Debian released 2.2r5 on January 10, 2002. 2.2r4, was released on November 5, 2001. 2.2r3, was released on April 17, 2001. 2.2r2, was released on December 3, 2000. To me, they both seem to maintain about 2 releases per year.
.TGZs and building your own cutting edge system.
/etc/apt/sources.list towards the Debian archive to upgrade to Woody.
Of course, Debian is very conservative, issuing only bug fixes and security patches, and strictly limiting new development for each new major relaseWoody. OpenBSD releases are also stable compared to Debian, but the development isn't segregated from the bug-fixes via Feature-freezes with Major/Minor releases as in Debian. Off the top of my head, OpenBSD had some significant changes, including XFree86 4.1 and PF replacing IPF.
You say that by the time releases come out, software packages are out of date. I have to challenge that - cutting edge packages are by definition not stable, and a package being "out of date" doesn't mean that it is obsolete just because a newer version exists. Bugfixes are not a valid excuse to upgrade to the latest version of a software release, as you may add just as many bugs as you fix. The Right Way is to backport fixes, which Debian does on a regular basis. Additional features are only significant if you find them useful, they don't make your current version any less useful. If you find that you need features added in a newer version, then it is trivial to apt-get update leetproggie.
If you think that rolling your own version of a package is preferable to a guaranteed working version, that means that you shouldn't be using a distribution: you should be grabbing your own
As it was already established that you shouldn't be relying on a stable distro but rolling your own system, you shouldn't need to rely on an installer. Just extract your Linux filesytem from a tarball and be done with it. You can roll your own options, so why do you need an installer to walk you through it? If you are as leet as you imply, the Debian installer is ideal... it allows you to use the shell to complete as many steps as you wish, and will take over from where you left it when you start to trip over your own feet. What is so awful about the Debian installer? It isn't a WIMP GUI? What are some of these "many bugs, etc."?
If you really need a WIMP (Windowing Interface, Mouse Pointer) then you should look into Progeny Debian, which made a good installer (read: point and click) which leverages the packages. The same GUI installer is reused for later reconfiguration of the system as well. Unfortunately, Progeny no longer sells their GUI improved version of Debian (Newton release, a meld of Potato and Woody) but you can can still find an ISO if you would like to try it. If you become comfortable with the Debian CLI subsystem, you can always point
As for your personification, you should at least qualify Debian as having High Functioning Autism, or perhaps Asperger's Syndrome. But the prognosis is very good, as Debian has an excellent support community. And that obsessive mind works quite well with clearly defined rules, which makes the Debian Policy Manual quite a boon with the thoroughly defined package dependancies superior to competing operating systems.
It seems that you misunderstand - Alien works great, it makes RPMs, DPKGs, and TGZs interchangeable. Your problem comes from the fact that Redhat RPMs (like Debian DPKGs and Slackware TGZs) also contain control information, effectively shell scripts that rely on the filesystem of the intended distribution. Since Redhat and Debian (all releases) use differnt locations for e.g. their rc.X files (initscripts), the control information isn't portable.
/opt directory was completely unsed by Debian, and AFAIK has always been that way. Since the release of Potato, something as laborious as moving every single changelog, readme, info page, man page and other textual file from its previous location (usuallt /usr/doc) into the FHS mandated /usr/share/doc hierarchy. This was of dubious benefit at best, other than strict adherence to the FHS.
.TGZ archives, and Free Software Operating systems should respect the conventions... especially in the common case where the software project existed longer than the OS in question. For the most part, the Free Software BSDs have done this. FreeBSD developed their Ports system allowing them to keep a tree of makefiles which would aid in compilation of software packages that isn't part of the standard system. The exception is that the BSDs tend to have integrated XFree86 into their "base system", so they have modified XFree86 from the standard distribution. Debian has gone much further than this, packaging almost any Free Software of interest, for inclusion into their system... making Debian the largest, most versatile system to date.
The Linux Standards Base is a fairly useful effort, but it includes the Linux Filesystem Hierarchy Standard, which seems to be what you intended to take Debain to task for. AFAIK, the RPM standard is specified only in the FHS, and not directly in the LSB. So you meant "Debian supports the FHS via alien..."
The FHS is full of good intentions, but unfortunately the reality falls far short. DJB has a number of valid criticisms that are as of yet not addressed by the LSB, or more accurately, the FHS. While I tend to think that standards are a good thing, I don't think that you should ignore convention in favor of provably flawed standards, so the FHS is not as desireable as I once felt. Without regard to the benefit of the FHS, I will argue that Debian supports it, in fact the Debian Project has made FHS support a specific requirement in their official policy manual.
The part of the FHS that you seem to be missing, is that while RPM is the official packaging format of the FHS, that doesn't mean that Redhat is automatically compliant. Rather, the standard RPM format is that defined in the publication Maximum RPM, and Redhat has continues development of their RPM format since that time. That means that the average RPM distributed with Redhat is not FHS compliant. Offical standard RPMs are handled by Debian via Alien flawlessly, and likely by Redhat and SuSE as well.
More importantly, the "Maximum RPM" RPM format isn't the most important feature of the FHS. More important is adherence to the recommendations of where in the directory tree different types of files should be. It seems that Debian is the most compliant distro, closely followed by SuSE last time I saw a comparison. You may have noticed when you administered the Debian Boxen that the
Just a small point of contention, every "Linux distribution" can arguably be called a distinct OS -- Unless you support that they are all just implementations of the GNU OS. But NetBSD and FreeBSD are just distributions of 386BSD. OpenBSD is just another version of NetBSD. AIX and IRIX are just distributions of UNIX. Even if all Linux distros are unified by the LSB, that's not much different than how all Unices have been unified by the POSIX standard. And Remember, Debian keeps their own Linux tree, as does Redhat, both distinct from the Official Linux at Kernel.org.
Theoretically, software developers should only have to release their files as
As a Red Hat user, it it is unfortunate but understandable that you didn't know more about the FHS and APT when you administered the Debian boxen. Perhaps you would have realised that you were likely using a non standard RedHat 7.x (e.g.) specific RPM. Even Mandrake, which directly descended from Redhat, has enough of a delta from Redhat that not all RPMs will interchange between the two. RPMs intended for other distros will tend to fare much worse. Even an RPM for Redhat 6.0 isn't recommended for Redhat 7.3, so it was a bit naive to expect a non-FHS RPM to work. Better would have been to type:
apt-cache search pppoe
If you wanted to install Roaring Penguin's PPPoE RPM to see it it was available, and what the APT package is named. If you had an RPM that you needed to install, then odds are that it was available. Then you type:
apt-get install pppoe
and all would have been well. Even if you had the FHS compliant rp-pppoe.RPM, using the APT/.dpkg version would be preferred, as the DPKG format has superior dependancy handling.
I am heartened to see that you haven't been down modded, I I hope that my post has been informative.
-castlan