I am already sold on the advantages of Debian over most RPM systems in general. I would like a reply with some info on why FreeBSD is better than e.g. the NetBSD packages/port.
Would you sentence have been better stated as "If you need Linux, use Debian, otherwise use *BSD."
Can you please describe what you know about The pros and cons of FreeBSD versus other BSDs like NetBSD, OpenBSD, Darwin or BSDi? Do you know anything about OpenPackages?
I don't quite understand why RPM has been mentioned more times than APT, dpkg and alien combined. This thread is supposed to be about Debian, not RedHat or the LSB. Nobody has even mentioned apt-rpm yet, which is at least periphially related to Debian technology.
I don't install new kernels from RPMs, I install them from dpkgs, usually using apt. I don't consider myself a linux user - I consider myself a Debian user. I consider myself a user of the Free Gnu OS, of which Linux is just one optional part. I look forward to being able to use APT to upgrade my kernel away from Linux.
And FYI, more than a few times, I have heard in the popular press mentions of Red Hat as an OS, without calling it "Linux". I'd hardly say that the rote typing of four lines in a BASH shell makes you more of a "linux" user than the next geek. I'd like to see you install a functional Linux kernel without utilizing a previously installed (by RPM? Tar.gz?) Linux kernel. Even more impressive, to be a literal "linux user" you should avoid the GNU toolkits.
As this runs on a Linux kernel, the multitasking is great. I'm sure you were referring to the "pervasively multithreaded" aspect of the BeOS, and in this aspect, Simply GnuStep no doubt falls far short. Most current Gnu/Linux distributions use XFree86 3.6.x and 4.x, which are singlethreaded... only one X11 application can be resonsive at a time. It is not clear that Simply GnuStep uses XFree, so it is possible that it may fare better wrt responsiveness. Using the current framebuffer support instead of XFree86 4.x would mean that 3d rendering won't be able to use hardware acceleration, but in that aspect it would strongly resemble the BeOS. I hope that this project will provide an impetus for adding acceleration to Framebuffer drivers.
As for multimedia, the BeOS had media translators. If you had the MPEG translator installed, then all applications had access to MPEG formatted files. Linux doesn't currently provide similar functionality, each individual application needs to support its own files. I doubt that GnuStep provides such funtionality, but even if it did, it wouldn't be as thorough as the system that was in place in the BeOS
As for FreeBeOS, it was a free download at around 50 Megs, but then you had a 500 virtual partition to play with. Simply GnuStep is 110 Megs, and must be burned to a CD before use. this is good as it doesn't use any disk space once burned to a CD, but it also means that you can't readily save any of your work. Then again, this is only a preview release... you may recall that previous free BeOS releases had similar retrictions. Simply GnuStep is hardly finished...
HanzoSan, I disagree - your post is definitely flamebait, and it should be moderated as such. Nowhere did digital_gh0st even mention KDE, GNOME, or windowmanagers in general. It is difficult to see why you would respond with accusations of bashing specific UI enviroments, when the poster is probably not even running an X server on the Pentium 100 Debian box.
You are also off the mark when you say "powerful" software. The term you are looking for is "bloated" software. With a less powerful machine, it is unpleasant to run bloated software. Powerful and weak are subjective terms, but they don't seem to fit your usage of the word. Does "weak" software even allow you to add plugins? "Powerful" software doesn't necessarily even use graphics... many would say that powerful software needs only a command line.
Don't worry, you were not being overly critical. Your perspective is likely more coorect than mine, as I was posting from a perspective near zealotry - namely, that the BeOS is very near to the pinnacle of OS and/or GUI design, as opposed to the statement in your earlier post.
The advantage to having a microkernel architecture paid off as BeOS's new and untested (compared to most preexisting systems) network stack could be flaky, but you could easily change it on the fly without affecting the rest of the system. The highly imperfect network stack would occaisionaly choke for a few reasons, but even if it got killed, it was trivial to restart it and continue using the system with little interupption. This may not be as good as having the time-tested BSD stack, but it is scalable enough that it is concievable that the BeOS network could improve.
Unfortunately, the attempt at fixing the weak (compared to many Unixes at least... weak is definitely relative here) by Be was to integrate it into the kernel. Sone the unreleased BONE system would have sacrificed any advantage derived from a microkernel architecture. That alludes to the biggest problem with BeOS : While it was designed by talented engineers without limitations, they were not equipped to handle the market realities of implementing their system. It is possible that an embracing an Open Source strategy more fully could have helped them, but it is also possible that they would have been consumed much earlier if they had tried tht approach.
They tried to be the pinnacle of OS design, by flaunting legacy compromised. For example, most early PCs didn't have enough Video RAM to support a windowing environment, so for many years they were command line only. After average PCs had suitable graphics hardware, Windows took over where DOS once ruled. BeOS didn't even bother with a command line environment... if you need a command line, then you can open a terminal window. They never even considered supporting technology that was considered old when they started. Similarly, Win3.1 True Type fonts were already well established, so they didn't even bother with Bitmapped fonts. Perhaps Anti-aliasing wasn't up to par yet, if you feel that the fonts weren't sufficient for you. But perhaps you have become accustomed to having the bitterness in your drink, as evidenced by your preference for the (IMO) cruder Windows mouse driver over the slicker Mac mouse movement. Ideally, both systems should be able to adjust the mouse input to your tastes, so if the BeOS could not, then that was also a shortcoming. The biggest flaw in the GUI, as in all non-Windows GUIs, is a deficiency in the keyboard bindings in the interface. It is likely a positive side effect of their non-GUI legacy, which might make up for many of the negative side effects. To date I have not used a GUI that is as effective from the keyboard as is Windows (win32 and 16 bit GUIS).
But despite all of these flaws in the over all OS, in my experience BeOS was the pinnacle of WIMP GUIs. That is, using windowing environments with a mouse pointer. It took many of the great Macisms, added in some Win-flavoing, and innovatively improved upon both in a still unmatched level. The few mistakes thay did make in that arena (choosing to fix the Win mistakes while unnecessarily altering the Mac defaults - as in the ctrl/alt tab fiasco) still don't make the BeOS GUI less usuable than the GUIs of current systems (MacOS 9, MacOS X, WinXP, Win2K+98, GNOME, KDE... an I missing any?)
Even though Be had to go away, I am glad to see a BeOS community sprout up under the Open Source Aegis, and doubly glad that Be expired before BONEing up the BeOS... without being a microkernel, it has that much less to live for. So FreeBeOS with the distinct networking services will likely see the light of day, and I can't wait. Even more importantly, other than a few crumbs with GNOME, I have yet too see a proper reinvention of BeOs's Mime-types as file identifiers. Linux as of 2.4 with the VFS does seem to have metadata capability suficient for BeOS style usage, but it remains to be seen in that lumbering beast will even notice _that_ particular flea on it's back. Again, Win2K on NTFS, besides having the keybindings, handles metadata well. As of today, with MacOS X stil having too high a point of entry, Win2K is unfortunately my preferred system, until GNOME on Linux takes better advantage of what it has, or FreeBeOS comes onto its own. Win2K is actually a fairly good system, which delivers enough of it's promises to be genuinely useful. But even if Windows doesn't go away (as you say, like Be), it still breaks.
...Not as badly as XP still does though. Never use MS products without (AT LEAST) one service pack/patch/point release.
Perhaps you are correct, as I have not actually examined the Octane 2's innards to see for myself, but the documentation for both systems refer to "VPro graphics". I may have assumed too much here, so I recant. But I would like clarification.
You point out the areas that Windows "ruled", but it seems that you are leaving something out, because AFAIK, OS/2 also has
1) backwards compatibility with DOS apps,
1.5) backwards compat. with Win 3.1 apps,
which leads to 2) software availabity,
3) AFAIK, OS/2 could utilize DOS drivers.
OS/2 was just not a priority for Big Blue, almost an unwanted burden judging from their actions. That more than anything, is not only why OS/2 didn't do well, but why Microsft even exists in the capacity they do today. As talented programmers, MS was still in far too hostile an environment without the unperceptive support of IBM to shoulder their expenses.
As for Today, Linux is hardly in the time where dinosaurs roam... commodity PCs are very cushy for Free Software, and Linux has all of the areas you mention covered in spades.
Of course "Linux" will not compete with Windows, a kernel is not an operating system. GNU is available, and has fulfilled its purpose as being a freely available and functional system for hackers. None of the reasons you mention prevent GNU/Linux from replacing windows.
Until somebody with enough resources and determination makes consistency and ease of use the priority, not an afterthought, then GNU OS will retain it's high level of entry. OEMs also have to be convinced of GNU's marketabilty, which is where the Open Source Initiative is finally making its presence known.
I didn't have extensive experience with the Old BeFS, or in depth knowledge while I did, so I can't speak with much certainty about it. But with the psedu-database implemented in the New BeFS, disk performance is much better than Mac Filesystems, and tends to be _slightly_ better than Windows Filesystems (in my experience). I suspect that more than a performance issue, is more of the complexity inherent in maintaining standard (POSIX) filesystem semantics with this database, with limited engineers to work on it. I understand that actually using a filesystem with directories was an early on compromise for the sanity of the understaffed team. Te original, idealistic plan was to do away with standard filesystem semantics altogether, and make use of the database of attributed for those purposed instead. BeOS really did try to avoid legacy cruft (read: backwards compatibilty) for JLG's vison of where modern computing should be.
As for OpenGL, you have a very good point. Even the best software rendering won't compete with proper hardware acceleration. Not having a Voodoo 3, I couldn't comment on that either, but it would have been nice to see.
They did support G3 processors, which was of very little use considering Apple under Jobs changed the motherboard and withheld the necessary engineering info from Be. The last (9500/9600? MP?) revision of Apple 604 motherboards didn't work properly either, but a support motherboard with a G3 upgrade card would work.
Perhaps it wasn't the pinnacle of GUI design, but I've never used a Lisp machine. I've used various revisions of Windows, MacOS, IRIX 5.x-6.5, AIX(CDE), KDE, GNOME and a bit of NeXTSTEP and Solaris(CDE), and Besides a bit of eye-candy with drop-menus (Start button) in never revisions of Windows, I'd be hard pressed to pick a hands-down better GUI than BeOS. The BeOS could even fake the Window-managers of Win9x, MacOS classic, and Amiga Workbench, but all of them reduced functionality available to the standard Be window manager. One of the most standout features, apart from the sheer responsiveness under load, was the abilty to trivially browse many folders deep in seconds using the right mouse button. I've seen similar functionality in the Now Utilities add-on to MacOS 7.x, which broke with MacOS 8. Could you please point out some GUI problems?
As For OS design, the only problems I am aware of were direct consequences of the "clean from scratch" design, basically meaning all hardware drivers had to be written from scratch. This would have been fine on the original hobbitt based machine and on the ppc BeBox as long as standard Network and Display devices were supported. This situation even improved on the closed Mac Platform, until they were shut out from Jobsian revisions - but it was bound to fall apart on the unregulated IA32 architecture.
While the hardware driver issue was critical, I can hardly blame it on OS design. One of my more wizardly kernel hacking friends informed me about some low-level trouble resulting from the exensive use of C++... but on the whole, the Os was a very well designed, flexible and highly performant Microkernel design. Using Mime types internally was inspired, the SGI derived filesystem was delicious (when finally paired with a chkdsk-type utility) and the copious metadata added enourmously to expressive capability accessibe to the system. The pervasively threaded Gui was unequaled, and if you ever did manage to lock up the interface, you could always telnet in Unix style and kill any offending process, and restart it again from the command line.
With hindsight, I can see how maybe the highly modular microkernel could have been leveraged to provide a hardware interface with a windows or Linux driver compatibilty layer - it might have immensely increased immediate usability if feasible. But can you point out some of the significant share of problems to me? Just about every one I have seen (other than marketshare, obviously) has been fixed.
Or maybe I'm still in my BeOs dream world. Wake me up... the loss of Be Inc. doesn't affect the CD still in my possesion, can you raise some of these issues for me? I've raised my own share, but they all have solutions, especially if you have the right hardware. Other than some long-term promise I see in bits of GNOME, I don't see anything else coming close to the strong points in Be.
I think you misunderstood the point I was trying to express. I in no way inteded that RedHat is the only significant "Linux Distro", or that there is a conspiracy against any other distributions.
My point is that there is no Operating System distribution that can accurately be called a "Linux Distribution". It would not be appropriate to call RedHat an "Apache Distribution" just because Apache httpd is on the media. Apache and Linux are just packages included on the disk to enhance the usefulness of the system. Linux is a kernel, RedHat is one of many distributions of the GNU system.
If your posted email address is accurate, then I can assume that you are a freshmaker who is already very aware of this issue. The only logical assumtion, if this isn't "gnus" to you, is that you neglected to read most of my post before responding.
In Unix, there is the concept of an unprivileged user. Unfortunately this is not adequately reflected in implementation. There are poor attempts to emulate this functionality by having non-user "users" such as daemon, nobody, mailer, or creating a "user" with the name of the program. There is the unfortuante choice between large numbers of bogus users polluting the passwd file and needlessly inflating UIDs, or creating few overpriviledged daemon users that are as vulnerable as the buggiest program in use, which can be as bad as comprmising root, and the entire system. Even an "unprivileed user" still has priviledges, as it is a user nonetheless.
The HIRD actually recognizes that daemons should be unprivileged. There is no user, the UID is null. If a service is compromized, then the rest of the system is insulated, specifically because that service does not run as an "unprivileged user", or any kind of user whatsoever.
Sentence 1 is disputed. As for sentence 2, I agree: "Pure fucking genious."
-castlan
Re:Hurd vs Linux vs *BSD
on
Hurd: H2 CD Images
·
· Score: 3, Interesting
It looks and acts just like Debian because it is Debian.
There seems to be much confusion in the philosophical, technical, and intangible Free Software world, I wonder why?
Debian is an operating system, that is an interface between the user and underlying hardware. If you will pretend with me that MS Wordpad is a reasonable word processor, then there is no reason to have to buy any other software for a basicly functional system. In this context, you can understand why MS had a valid reason to consider Internet Explorer an integral part of Windows... because the Web became significant. Earlier, MacOS included MacWrite, making WYSIWYG word-processing a significant part of the "operating System"... you get it now.
The Kernel isn't important to the OS, other than that there is something interfacing the higher level systems to the low level hardware - consider Windows NT 4.0 and Windows 95. They have the same basic userland minus a few changes, even though the underlying systems are completely different, i.e. a 32 bit microkernel in NT versus an 8 bit monolithic kernel in 95. Both have 16 bit Windows components integrated.
Likewise, Debian is a consistent operating system... namely, an incarnation of the GNU operating system. This GNU operating system is the realization of the GNU project, an OS that you can share freely with your friends without worrying about any corporations taking away that right.
But Debian is Linux! Right? No, Debian uses Linux. Debian GNU/Linux and Debian GNU/Hurd are both GNU, with Debian policy and integrated management utilities. There are slight differences in the userland, major changes in the underlying system... but you don't directly use "Linux".
Yes, that also means that RedHat is GNU.
While Redhat uses Linux, that doesn't mean that RedHat "is" Linux. But for the sake of Redhat's marketshare, they are willing to ignore that fact. Wall Street doesn't care that "Guh-new" wants "hackers" to be "Free", or even that it is a clever little recursive acronym. They care that "Linux" is recognizable for investors of software developers, like "dot-com" and "information superhighway". Linux sounds cool, money is cool, that's why were here, put it on the label.
If you are are using Windows NT, you aren't using the underlying hardware... the HAL, the microkernel components... at the lowest level most users see, your interface is the command interpreter. Usually you use the Explorer.exe interface. With Win 95, without the underlying components, the lowest you'll see is still the command.com text interface, ot the Explorer GUI.
If you are using a GNU (GNU/Linux) distribution, you aren't using your computer's internal hardware, or the Linux Kernel. If would be very uncomfortable to try using Linux without at least a BASH interface running atop, to accept input from you the mere user.
The issue isn't that of using the Hurd instead of Debian, Debian will use the Hurd as well as Linux. The issue is that of using The Hurd instead of Linux in your Debian system. Theoretically, the difference can be compared to using Win NT 4.0 instead of Win 95. That is, poorer hardware support, somewhat less simple subsystem configuration, but the promise of a microkernel proving to be more robust than a monolithic kernel like Linux.
More significantly, and more exclusively, is the fact that DOS runs on pre-386 computers. Linux does not, not even netBSD will do that.
DOS will run with significantly less than 5 Megs of RAM, Linux tends to have major issues develop somewhere in the range between 3-5 Megs. Of course you might be able to counter that Linux has no trouble accessing over 640K. Touche'.
Well, how about boot time? A DOS floppy boots faster than a Linux floppy. (Not even GNU, just Linux kernel on a floppy). And the shutdown sequence tends to be significantly shorter.
Ohh! Best of all, Much like OpenBSD, DOS is "secure by default". No remote root exploit in the default configuration in over _20_ years! Beat that, you Canadian mountain biker!
Do I have a point? Moderation speaks louder than words! But if you don't have mod points, a reply will suffice.
I would have say that "too good" was a poor choice of words, but the sentiment was correct. Perhaps "ahead of their time" is more accurate.
Sgi tends to be ahead of their time, which can be a good thing in their standard market of high end machines, but disasterous in the commodity world of ia32 PCs.
That they decided to "mess with the voltages for no apparent reason" is understandable unless you are comming from the commodity PC world. Standard x86 processors were all depended on 5V connections. Later, to aid in effeciency and higher clock speeds, they were reduced to 3.3V. You may remember the trouble with "Overdrive" enabled motherboards that were intended to be Pentium compatible before the Pentium part was available. By the time Pentiums were common, they used 3.3V, and so did their motherboards. Overdrive MBs needed to buy specific Overdrive CPUs that ran at 5V.
Well, as part of the PCI2.1 spec, there can be "2x" 66MHz connections, as well as 64 bit as opposed to the "standard" 32 bit connections. PCI boards need to be keyed to fit in the properly keyed PCI slots... there can be Universal cards that work at either 5V or 3.3V connections. Unfortunately for the 320 and 540, commodity low PCI cards didn't yet have enough reason to put out 3.3v wide or double speed compliant PCI cards. From SGI's end of the spectrum, the more performant cards were already standard, as they were necessary for e.g. gigabit ethernet, FDDI and other technologies in wide use by SGI consumers.
I've never heard anything like what you describe with USB... but I can't discount it outright because at the time I wasn't aware of very many USB consumer devices available on the market yet. But as for "firewire" ieee standard, SGI was again ahead of their time. They wanted the cutting edge connector on their hardware, but unfortunately the machine shipped before the standard was formalized, so there were inoperative ports on the visual workstations. If you needed those ports for digital video, then they would have shipped you the (high performance) pci cards for free.
As for the proprietary RAM, it was a shame that it was so expensive. But, it was sweet, and still nothing to sneeze at to have a system with 2 gigs of RAM. And though most pc lusers (like myself) still don't need such high performance ECC ram, it was a UMA system, meaning you could tell NT that you would like to allocate a chunk of it to display hardware. To date I'm not aware of NVidia shipping anything capable of 512 Megs of video ram. Having the Graphics hardware as tightly integrated into the system meant that it was capable of some impressive throughput, much like the O2. Unfortunately, tying yourself that thouroughly into your prediction of the future can be problematic, especially in the commodity technology arena when the main competetor is comprised of many of your own ex-engineers. No amount of RAM will make up for the lack of Transform and Lighting hardware for real time rendering, and they should have put more of their Reality Engine tech into the 320 and 540 Visual workstation. That would have made their much more profitable O2 Visual workstation obsolete, and so they crippled the x86 Visual workstation line. Too bad they didn't integrate (at least one) AGP slot, which at 1x didn't have to be much more difficult than a standard 2x PCI slot.
They gave up on it with their later line of 230 Visual Workstations, which cooperated with the commodity vendors NVidia by using commodiry motherboards.
But one thing that they got faulted for, more than any other, should have generated MUCH praise. That "seriously weird boot sequence" is something I'm dying for today, as It would make booting Linux much better unified across different platforms. SGI's GUI PROM bootloader is infinitely superior to the common pc's archaic and proprietary BIOS. As you may recall, the BIOS was IBM proprietary. While Compaq was able to reverse engineer, it is still the same crufty inflexible system that we started out with, virtually unchanged from 1980. Not because it was so good, but because it was so difficult to hack around and still be backwards compatible with the "IBM PC". Consider such nonsense as IRQs and CHS. IRQs got hacked up to 15, still not good enough, so there are elaborate IRQ sharing schemes in place... lets hope you don't need more expansion then that will allow. As for CHS, nobody needs more than 500 MB of disk, right? oh, well just invent an elaborate translation scheme where each subsystem thinks that any given disk block is located in a different place... that will give 2 Gigs. Oh, that can be expanded too, just as long as you don't need to boot from it.
Lilo is far from the ideal Linux booter. Grub is much more flexible, but it's no OpenFirmware. Both Apple and Sun have this far superior facility for bootstrapping their system. SGIs elegant PROM made LILO apparent as the crufty hack it was; you could use your mouse to navigate, or you could use a remote console via serial port, you specify where the Linux Kernel was located, or NT would specify it for you during the install. No other bootloader, not even GRUB, can boot both NT and Linux.
Yes, SGI screwed up with locking in the graphics hardware, which was summarily leapfrogged by their own T&L tech embodied in NVidia. They overestimated PCI card makers and jumped the gun connectivity wise, be it PCI2.1, LVD SCSI, openLVI or "firewire", the opportunity to free us from our cursed "established market" standard PC BIOS should have been a breath of fresh air, and was hardly an attempt to screw us over. It is a loss I mourn at least once month as I wait, still hoping that GRUB, or openBIOS, or something better comes along with which to boot my system.
Maybe I should just get more money and buy a Mac. Or even more money for a Sun. Or I could hit the lottery and buy a post-Octane 2 Unix workstation. Guess I'll just suck it up with El-torito, GRUB, and LBA addressing.
SGI already did the co-operation thing with NVidia... that's where NVidia's binary XFree drivers came from. That is also how much of the DRI structuring for Xfree86 4.x came about.
As Temkin said, NVidia was largely composed of former SGI people, which explains why the NVidia graphics chips are so perfomant. In fact, the hardware was too good... much of the technology violated SGI patents.
As part of the resolution, they teamed up for the SGI 230 and 540 series of "Visual Workstations" which were basically standard ia32 PCs with professional higher end versions of the geForce called Quadro. They got the best silicon, and what was left was user for the consumer NVidia cards.
The Octane 2 has "much more powerful chips at much lower prices" as a result, it is basically an NVidia graphics chip welded to the Octane's crossbar architecture. Of course, when you talk about SGI/MIPS workstations, "lower prices" is still a relative term.
So your "what if" questions got answered... commodity hardware running free GNU variants supporting free accelerated X11 capable of running immersive 3d environments worthy of Classic SGI demos like Performer Perfly, or even Quake!
Or maybe you aren't aware that there is a R5 release available for PPC. The BeOS R5 Pro CD contains BeOS for both i586+ and PPC 603x/604x PCI motherboards. 3 partitions, one BeFS PPC, one BeFS x86, and one Universally readable iso9660 partition cantain the entire system, including source code for the GNU utilites and boot loader executables.
-castlan
I would like to know if you have a response for this, but moderator points force anonymity. Hope that you find this helpful.
That sounds like you are taling about the standard UNIX encryption library, which is visibly used for the standard UNIX passwd command. You cannot determine what the password is by performing matematical transformations on the/etc/passwd contents.
Instead, we use passwd to perform the transormations on what we suspect the user used for the password. If the output is the same as the previously encypted password in/etc/passwd, then there is a match.
To exploit this, you passwd-encrypt a dictionary of words, and then see if any of the output matches an entry in/etc/passwd.
Or, you could just capture the traffic now, and run a modern cracker against it. By the time quantum-computing technology becomes consumer-level technology, it is likely that anything you have a significant interest in will have been cracked. Just don't ever turn off your computer.
To venture out on a limb and make a statement that I should not make, being that I am crytographically challenged:
Why not just use a 1 bit key? Anybody that knows how to crack your message can get the job done anyway, but it would still keep your content private to the general public, with minimal CPU expenditure. I an ignorantly guessing that XORing your data qualifies?
Actually, all of the above is bullshit. I just wanted to be a nudge and point out some possible exceptions to the statements made in your signature.
It is very probable that somebody got fired at SGI for choosing Microsoft, probably each time it happened (NT4-MIPS with ARC booting, SGI Visual Workstations using NT4-x86 with ARC booting...) It's likely the decision to base the AOL web-brower on IE wasn't highly rewarded either.
I'm also sure that many fools have been exposed by trying to run a Linux based OS on a Token ring network. Those involved in the OpenBSD project would probably mave some interesting alternatives to praise ready for any who would suggest that they host their web site on RedHat Boxen.
I must really be itching for some negative mod points here... Perhaps I should have encrypted this message before posting.
Theoretically there is no reason why there shouldn't be infinitely many distinct distributions of Linux. My having an unrelated distro really shouldn't have any tangible effect on your distro. Most of the concievable negative effects are negated by following the LSB, if not the FHS. The only significant problem I see is that of a newbie being overwhelmed by their initial choice, if they don't have any criteria to choose their distribution by.
This is why is would be good to have a central resource that has a taxonomy of Linux distributions, along with user rankings of different aspects of the various versions of differing distros. That way, by answering a few simple questions a newbie could be guided to the highest quality distro that fulfills their criterion. I know of at least one web site that has a compilation of the various distros available, but I am not certain of any that have a useful ranking.
Now I don't see why you allow for the choice between Mandrake and Red Hat. Progeny is at least as different from Debian proper as Mandrake is from Redhat. The most obvious difference in Mandrake is that during the standard RedHat install, it switches over to a much nicer graphical install that had a much more robust Hardware autodetection the last time I tried it. If you can point out some more distinctions between Mandrake and RedHat, then Maybe you have a valid point. As is, your bias is most unfortunate... RedHat and Mandrake add more to the distro glut due to overlap than Turbolinux does.
Progeny also has a nice GUI installer not available to Debian proper. I understand that Mandrake now includes Grub as standard over Lilo while RedHat doesn't... Progeny used GRUB from day one. And it was quite nice to have Progeny development seperate from standard Debian, as it allowed such packages as GnuCash with very complex dependancies to be prioritized for the commericial Progeny, while it is just about unusable in any standard Debian distro. One of the important qualities of Debian is that it does not have any kind of externally set release schedule, which is a large part of the reason the stability of the Debian distro far outshines the other distributions.
You seem to not understand The Debian system very well, which is very unfortunate. It is not inherently more complex, it just seems evident that you have never given it a real chance. Apt does not have some magical technology that far surpasses all other forms of package management. The advantage lies in the policy, and politics, which are inherently slow moving. The red tape of policy, while annoying if you have a political agenda, is great if you want a stable system. Apt doesn't isolate the apps, Apt just applies the rules policy dictates.
FYI, you can have the Stable distro and run the latest apache if you like. The most "stable" way would be to compile your own apache package, with proper dependencies set, and then install that. If you just want to install the premade package, you can do that as well... but it might require you to update some of your libraries to newer, less "stable" versions if the apache dependancies demande it.
Again, Debian development should not be "sped up" in the way you seem to suggest, which would imply relaxing the Debian policies. Those policies are the reason why Debian will remain the best long term solution to an operating system. The problem is when you need something "now" that might not be available yet... The best solution IMHO was the one Progeny pursued, basing their own distro off of the Debian standard sources. Then, you could "speed up" development for thiose components you consider most important as much as you like without hurting the rest of the Debian project. On the way, contribute your improvements back to Debian so that they can (over time) integrate your enhancements into the standard debian syste, (which spans many architecures.... there is a good reason why things much not move too fast). I definitely think that Progeny development has been cut short prematurely, and it is most unfortunate.
The existence of Progeny has at least as much justification as that of Mandrake. Being a "geek" is not the only reason to want a better system, and Progeny is still the best place for a newbie to start in my mind, as it is the easiest path to the stability and quality of a Debian system. The only reason I can see for Red Hat is if it is already company policy, because of long term support contracts already paid for. In this case, there is no reason to have Mandrake as the "easier Red Hat" as the support contracts likely won't cover the distinct distribution. If you are looking for a new support contract, I would still suggest Progeny, as they provide support for ANY Debian distro, including Progeny Debian. SuSE and TurboLinux are still valuable in Germany and Japan, respectively, though Debian is making much headway in those areanas as well.
Slackware is good if you already know it, and for current slackware users I would not recommend switching distros if it has everything you need. If you want to have a very "Unixy" system, as opposed to the fluff that Linux distros provide, Slackware is a good choice. I feel you are right in this aspect when it comes to "the geekier crowd", or those who are staunch in having a Unix that still feels like Unix. If you aren't a current Slack user, and you want a Unix system for the sake of Unix purity, especially for development, I'd probably suggest that you go with one of the BSDs instead. There are some that say that the *BSD Ports/Packages system is better than Apt... but I can' comment on that as of yet. For standard development I'd probably suggest NetBSD, unless you are directly on the internet, or have a multi-proc system.
Oh, BTW, I choose Debian, and for me the installer was a big deal. If you've never tried it, the Debian-cd image maker was an unpleasant bitch, especially behind my company's firewall. Having a cable-modem and boot floppies is much nicer, but I didn't have that luxury when I first tried Debian. I remember a tear of joy at finding the progeny ISO on their website when they first came out... I way anything but malcontent at that point.
While RPM and dpkg databases are very sophisticated compared to Windows Uninstall or Installshield, they are hardly all-knowing. Rather than tracking files, they know the files they own, that they installed.
In Debian, each file can only have one owner. If more than one package claims to own a file, than an error is flagged. But that doesn't necessarily mean that every file on the system is owned. Even if you don't count files extracted from the base.tar during older installs, there are many files that are generated during or after installing a package. Any file generated by an install time script instead of extracted from the compressed package is not claimed by any package. The uninstall scripts still have to remove dirctories specific to their application if they want to try to fully remove all traces of the app. Mind you, this is in addition to configuration files in/etc that may or may not be purged.
Windows Add/remove justs keeps track of files it explicitly installed. It then gives you the option to remove those specific files (or sometimes upgrade them). Debian is significantly more sophisticated in that it keeps track of dependancies, but it has yet to manage every non-user file in the system. So far, their stop-gap measure to manage this mess is the package cruft, which helps to scan the system for unclaimed files.
So, even with package management as sophisicated as Debian's, in the end the administrator still has to manage the files. Package management cannot supplant proper filesystem layout (...yet).
How in the hell was the parent moderated up to 3?
I have seen multiple solutions posted while browsing at moderator level 3. Am I going to have to start browsing at 4 now?
There is no standard in Windows like the FHS, only Microsofts latest guidelines which don't to my knowledge address proper Start menu behaivor. Every app I know that tries to put a shortcut directly in the Start menu gives an option between having it in the start menu, on the desktop, and in the IE launch bar. The exception I've seen is AOL launcher, primarily because it is preinstalled. I will agree that the Windows Start Menu needs a coherent management scheme published.
Limiting your experience to Red Hat and Mandrake and then proclaiming anything about "everyone's guily" is silly. Mandrake is all but another distribution of Red Hat. Might as well make a blanket statement after using Debian and Progeny. There are many statements praising recent Slackware versions for using/opt as part of a solution, for example. Slack is most unlike Red Hat and its many derivatives.
The FSS is not intended to make organizing one's hard drive any easier, but to make distributions less likely to interfere with your organization. That is what makes/usr/local useful. Perhaps the solution for you would involve/usr/local/apps,/usr/local/utils, etc. (/usr/local/etc?:P) Everything you compiled belongs within/usr/local/ if you choose to adhere to the guidelines set out in the FHS. Within that framework, you can organize by function, or whatever else you fancy.
As for the distribution system, I don't see that such arbitrary classification is as useful for filesystem layout as grouping by the application's title. There are better places for those distinctions, like in the "Start Menu". In Windows, ideally, everything is installed into its own directory as much as possible, while the Start Menu is grouped more by user functionality.
In response to the anonymous coward of message #2596088, in Debian, the best place for such things as/usr/internet or/usr/editor exists in the/etc/alternatives directory. Try "man update-alternatives". While/etc/alternatives/infobrowser exists for.html help pages, perhaps there sould be an/etc/alternatives/webbrowser entry.
/home is far from irrelevant. It is the only place where non-sysadmin related files should reside, unless they are being served over a network or removable media. Any non-root user should never have reason to leave/usr/home, provided all PATH environments are properly configured. Keeping personal files scattered throughout/bin directories is a better way to "sure-fire confusion".
The best way to have an organized hard disk is to have a reasonable set of guidelines you follow on filesystem layout. After that, just follow them! The best way to fight entropy, is of course, to do something useful! After you die, then you should emprace entropy. I suspect that the rhetoric of apathy in these two statements garnered your 2 "insightful" moderations. Give me a break, learn some discipline and organization.
----
As to the solutions that "nobody" has offered to this problem of clutered and unwieldly/bin directories, try browsing at a high moderator number, and see a range from:
1. No problem, who cares what the Filesystem looks like when the Package manager suits your needs;
2. Use one of the automated soltions listed at the Opt Depot like GNU STOW;
3. Keep all "applications" in subirectories in/opt, with appropriate links in/usr/bin. For systems w/package management, make that/usr/local/bin as in #2595732 4. Keep only one symlink for any "application suite" in/usr/bin, which calls the appropriate executable depending on its flag;#2598189 5. My least favorite - expand your PATH variable to include every/bin subdirectory in the/usr hierarchy. ##2595676
Note to self:
##2596072 gives a reference and addresses the shortcoming of current Debian Package Management - concurrent divergent versions of applications.
$ apt-cache search ldap2
libldap2 - OpenLDAP libraries.
libldap2-dev - OpenLDAP development libraries.
libopenldap1 - OpenLDAP libraries (obsoleted by libldap2).
$ apt-cache show libldap2
Package: libldap2
Priority: important
Section: libs
Installed-Size: 430
Maintainer: Wichert Akkerman
Architecture: i386
Source: openldap2
Version: 2.0.14-1
Replaces: libopenldap-runtime
Depends: libc6 (>= 2.2.3-7), libsasl7
Filename: pool/main/o/openldap2/libldap2_2.0.14-1_i386.deb
Size: 174132
MD5sum: 2a3b44f7c257d854e0a700624739e9ed
Description: OpenLDAP libraries.
These are the run-time libraries for the OpenLDAP (Lightweight Directory
Access Protocol) servers and clients.
Somewhat less than a full generation old in the Debian camp. OpenSSL is at least 0.9.6. Pine has to be built from source so as to not violate its copyright, but Debian provides the source and Debian diffs in their package manager all set to build. As for installing libraries, it works out fine if you use the package manager to do it. If you can build the libraries from source, then you are competent enough to make a package from that very same source. If there is a problem, then using the equivs package can convince your system that dependancies are met.
As for having the Package Management system look around your system to satisfy dependancies, perhaps Red Hat should do that. Debian dependancies are more sophisticated that "is that file present?" They need version information as well, which can be troublesome if you consider the variations possible with open source. Debian can only verify binaries which it generates. The best way to do that is by downloading directly from their archive.
Perhaps you mean to say
"underfuntional bloated web interfaces are your enemy"
or
"superfluous GUIs suck, CLIs are your friend"
or something along those lines. How about "libNEWT is your friend"?
I still support "SSH is your friend" despite it not being the point you seem to have intended, unless you meant it in reference to Web management consoles exhibiting great suckage compared to more straightforward textual interfaces. Then perhaps the SSH statement fits.
WRT port services, wouldn't netcat be a better answer than telnet? The way I see it, "telnet is your occasionally useful historian" for legacy purposes only.
Slashdot Mirror
I am already sold on the advantages of Debian over most RPM systems in general. I would like a reply with some info on why FreeBSD is better than e.g. the NetBSD packages/port.
Would you sentence have been better stated as "If you need Linux, use Debian, otherwise use *BSD."
Can you please describe what you know about The pros and cons of FreeBSD versus other BSDs like NetBSD, OpenBSD, Darwin or BSDi? Do you know anything about OpenPackages?
-castlan
I don't quite understand why RPM has been mentioned more times than APT, dpkg and alien combined. This thread is supposed to be about Debian, not RedHat or the LSB. Nobody has even mentioned apt-rpm yet, which is at least periphially related to Debian technology.
I don't install new kernels from RPMs, I install them from dpkgs, usually using apt. I don't consider myself a linux user - I consider myself a Debian user. I consider myself a user of the Free Gnu OS, of which Linux is just one optional part. I look forward to being able to use APT to upgrade my kernel away from Linux.
And FYI, more than a few times, I have heard in the popular press mentions of Red Hat as an OS, without calling it "Linux". I'd hardly say that the rote typing of four lines in a BASH shell makes you more of a "linux" user than the next geek. I'd like to see you install a functional Linux kernel without utilizing a previously installed (by RPM? Tar.gz?) Linux kernel. Even more impressive, to be a literal "linux user" you should avoid the GNU toolkits.
As this runs on a Linux kernel, the multitasking is great. I'm sure you were referring to the "pervasively multithreaded" aspect of the BeOS, and in this aspect, Simply GnuStep no doubt falls far short. Most current Gnu/Linux distributions use XFree86 3.6.x and 4.x, which are singlethreaded... only one X11 application can be resonsive at a time. It is not clear that Simply GnuStep uses XFree, so it is possible that it may fare better wrt responsiveness. Using the current framebuffer support instead of XFree86 4.x would mean that 3d rendering won't be able to use hardware acceleration, but in that aspect it would strongly resemble the BeOS. I hope that this project will provide an impetus for adding acceleration to Framebuffer drivers.
As for multimedia, the BeOS had media translators. If you had the MPEG translator installed, then all applications had access to MPEG formatted files. Linux doesn't currently provide similar functionality, each individual application needs to support its own files. I doubt that GnuStep provides such funtionality, but even if it did, it wouldn't be as thorough as the system that was in place in the BeOS
As for FreeBeOS, it was a free download at around 50 Megs, but then you had a 500 virtual partition to play with. Simply GnuStep is 110 Megs, and must be burned to a CD before use. this is good as it doesn't use any disk space once burned to a CD, but it also means that you can't readily save any of your work. Then again, this is only a preview release... you may recall that previous free BeOS releases had similar retrictions. Simply GnuStep is hardly finished...
-castlan
HanzoSan, I disagree - your post is definitely flamebait, and it should be moderated as such. Nowhere did digital_gh0st even mention KDE, GNOME, or windowmanagers in general. It is difficult to see why you would respond with accusations of bashing specific UI enviroments, when the poster is probably not even running an X server on the Pentium 100 Debian box.
You are also off the mark when you say "powerful" software. The term you are looking for is "bloated" software. With a less powerful machine, it is unpleasant to run bloated software. Powerful and weak are subjective terms, but they don't seem to fit your usage of the word. Does "weak" software even allow you to add plugins? "Powerful" software doesn't necessarily even use graphics... many would say that powerful software needs only a command line.
-castlan
Wow, thanks for pointing out the website... It's good to see RedHat putting their mouth where their money is, so to speak! :D
Guess I should have wished you a happy "GNU" year!
-castlan
Don't worry, you were not being overly critical. Your perspective is likely more coorect than mine, as I was posting from a perspective near zealotry - namely, that the BeOS is very near to the pinnacle of OS and/or GUI design, as opposed to the statement in your earlier post.
The advantage to having a microkernel architecture paid off as BeOS's new and untested (compared to most preexisting systems) network stack could be flaky, but you could easily change it on the fly without affecting the rest of the system. The highly imperfect network stack would occaisionaly choke for a few reasons, but even if it got killed, it was trivial to restart it and continue using the system with little interupption. This may not be as good as having the time-tested BSD stack, but it is scalable enough that it is concievable that the BeOS network could improve.
Unfortunately, the attempt at fixing the weak (compared to many Unixes at least... weak is definitely relative here) by Be was to integrate it into the kernel. Sone the unreleased BONE system would have sacrificed any advantage derived from a microkernel architecture. That alludes to the biggest problem with BeOS : While it was designed by talented engineers without limitations, they were not equipped to handle the market realities of implementing their system. It is possible that an embracing an Open Source strategy more fully could have helped them, but it is also possible that they would have been consumed much earlier if they had tried tht approach.
They tried to be the pinnacle of OS design, by flaunting legacy compromised. For example, most early PCs didn't have enough Video RAM to support a windowing environment, so for many years they were command line only. After average PCs had suitable graphics hardware, Windows took over where DOS once ruled. BeOS didn't even bother with a command line environment... if you need a command line, then you can open a terminal window. They never even considered supporting technology that was considered old when they started. Similarly, Win3.1 True Type fonts were already well established, so they didn't even bother with Bitmapped fonts. Perhaps Anti-aliasing wasn't up to par yet, if you feel that the fonts weren't sufficient for you. But perhaps you have become accustomed to having the bitterness in your drink, as evidenced by your preference for the (IMO) cruder Windows mouse driver over the slicker Mac mouse movement. Ideally, both systems should be able to adjust the mouse input to your tastes, so if the BeOS could not, then that was also a shortcoming. The biggest flaw in the GUI, as in all non-Windows GUIs, is a deficiency in the keyboard bindings in the interface. It is likely a positive side effect of their non-GUI legacy, which might make up for many of the negative side effects. To date I have not used a GUI that is as effective from the keyboard as is Windows (win32 and 16 bit GUIS).
But despite all of these flaws in the over all OS, in my experience BeOS was the pinnacle of WIMP GUIs. That is, using windowing environments with a mouse pointer. It took many of the great Macisms, added in some Win-flavoing, and innovatively improved upon both in a still unmatched level. The few mistakes thay did make in that arena (choosing to fix the Win mistakes while unnecessarily altering the Mac defaults - as in the ctrl/alt tab fiasco) still don't make the BeOS GUI less usuable than the GUIs of current systems (MacOS 9, MacOS X, WinXP, Win2K+98, GNOME, KDE... an I missing any?)
Even though Be had to go away, I am glad to see a BeOS community sprout up under the Open Source Aegis, and doubly glad that Be expired before BONEing up the BeOS... without being a microkernel, it has that much less to live for. So FreeBeOS with the distinct networking services will likely see the light of day, and I can't wait. Even more importantly, other than a few crumbs with GNOME, I have yet too see a proper reinvention of BeOs's Mime-types as file identifiers. Linux as of 2.4 with the VFS does seem to have metadata capability suficient for BeOS style usage, but it remains to be seen in that lumbering beast will even notice _that_ particular flea on it's back. Again, Win2K on NTFS, besides having the keybindings, handles metadata well. As of today, with MacOS X stil having too high a point of entry, Win2K is unfortunately my preferred system, until GNOME on Linux takes better advantage of what it has, or FreeBeOS comes onto its own. Win2K is actually a fairly good system, which delivers enough of it's promises to be genuinely useful. But even if Windows doesn't go away (as you say, like Be), it still breaks.
...Not as badly as XP still does though. Never use MS products without (AT LEAST) one service pack/patch/point release.
Perhaps you are correct, as I have not actually examined the Octane 2's innards to see for myself, but the documentation for both systems refer to "VPro graphics". I may have assumed too much here, so I recant. But I would like clarification.
You point out the areas that Windows "ruled", but it seems that you are leaving something out, because AFAIK, OS/2 also has
1) backwards compatibility with DOS apps,
1.5) backwards compat. with Win 3.1 apps,
which leads to 2) software availabity,
3) AFAIK, OS/2 could utilize DOS drivers.
OS/2 was just not a priority for Big Blue, almost an unwanted burden judging from their actions. That more than anything, is not only why OS/2 didn't do well, but why Microsft even exists in the capacity they do today. As talented programmers, MS was still in far too hostile an environment without the unperceptive support of IBM to shoulder their expenses.
As for Today, Linux is hardly in the time where dinosaurs roam... commodity PCs are very cushy for Free Software, and Linux has all of the areas you mention covered in spades.
Of course "Linux" will not compete with Windows, a kernel is not an operating system. GNU is available, and has fulfilled its purpose as being a freely available and functional system for hackers. None of the reasons you mention prevent GNU/Linux from replacing windows.
Until somebody with enough resources and determination makes consistency and ease of use the priority, not an afterthought, then GNU OS will retain it's high level of entry. OEMs also have to be convinced of GNU's marketabilty, which is where the Open Source Initiative is finally making its presence known.
I didn't have extensive experience with the Old BeFS, or in depth knowledge while I did, so I can't speak with much certainty about it. But with the psedu-database implemented in the New BeFS, disk performance is much better than Mac Filesystems, and tends to be _slightly_ better than Windows Filesystems (in my experience). I suspect that more than a performance issue, is more of the complexity inherent in maintaining standard (POSIX) filesystem semantics with this database, with limited engineers to work on it. I understand that actually using a filesystem with directories was an early on compromise for the sanity of the understaffed team. Te original, idealistic plan was to do away with standard filesystem semantics altogether, and make use of the database of attributed for those purposed instead. BeOS really did try to avoid legacy cruft (read: backwards compatibilty) for JLG's vison of where modern computing should be.
As for OpenGL, you have a very good point. Even the best software rendering won't compete with proper hardware acceleration. Not having a Voodoo 3, I couldn't comment on that either, but it would have been nice to see.
They did support G3 processors, which was of very little use considering Apple under Jobs changed the motherboard and withheld the necessary engineering info from Be. The last (9500/9600? MP?) revision of Apple 604 motherboards didn't work properly either, but a support motherboard with a G3 upgrade card would work.
Perhaps it wasn't the pinnacle of GUI design, but I've never used a Lisp machine. I've used various revisions of Windows, MacOS, IRIX 5.x-6.5, AIX(CDE), KDE, GNOME and a bit of NeXTSTEP and Solaris(CDE), and Besides a bit of eye-candy with drop-menus (Start button) in never revisions of Windows, I'd be hard pressed to pick a hands-down better GUI than BeOS. The BeOS could even fake the Window-managers of Win9x, MacOS classic, and Amiga Workbench, but all of them reduced functionality available to the standard Be window manager. One of the most standout features, apart from the sheer responsiveness under load, was the abilty to trivially browse many folders deep in seconds using the right mouse button. I've seen similar functionality in the Now Utilities add-on to MacOS 7.x, which broke with MacOS 8. Could you please point out some GUI problems?
As For OS design, the only problems I am aware of were direct consequences of the "clean from scratch" design, basically meaning all hardware drivers had to be written from scratch. This would have been fine on the original hobbitt based machine and on the ppc BeBox as long as standard Network and Display devices were supported. This situation even improved on the closed Mac Platform, until they were shut out from Jobsian revisions - but it was bound to fall apart on the unregulated IA32 architecture.
While the hardware driver issue was critical, I can hardly blame it on OS design. One of my more wizardly kernel hacking friends informed me about some low-level trouble resulting from the exensive use of C++... but on the whole, the Os was a very well designed, flexible and highly performant Microkernel design. Using Mime types internally was inspired, the SGI derived filesystem was delicious (when finally paired with a chkdsk-type utility) and the copious metadata added enourmously to expressive capability accessibe to the system. The pervasively threaded Gui was unequaled, and if you ever did manage to lock up the interface, you could always telnet in Unix style and kill any offending process, and restart it again from the command line.
With hindsight, I can see how maybe the highly modular microkernel could have been leveraged to provide a hardware interface with a windows or Linux driver compatibilty layer - it might have immensely increased immediate usability if feasible. But can you point out some of the significant share of problems to me? Just about every one I have seen (other than marketshare, obviously) has been fixed.
Or maybe I'm still in my BeOs dream world. Wake me up... the loss of Be Inc. doesn't affect the CD still in my possesion, can you raise some of these issues for me? I've raised my own share, but they all have solutions, especially if you have the right hardware. Other than some long-term promise I see in bits of GNOME, I don't see anything else coming close to the strong points in Be.
-castlan
I think you misunderstood the point I was trying to express. I in no way inteded that RedHat is the only significant "Linux Distro", or that there is a conspiracy against any other distributions.
My point is that there is no Operating System distribution that can accurately be called a "Linux Distribution". It would not be appropriate to call RedHat an "Apache Distribution" just because Apache httpd is on the media. Apache and Linux are just packages included on the disk to enhance the usefulness of the system. Linux is a kernel, RedHat is one of many distributions of the GNU system.
If your posted email address is accurate, then I can assume that you are a freshmaker who is already very aware of this issue. The only logical assumtion, if this isn't "gnus" to you, is that you neglected to read most of my post before responding.
Happy Gregorian New Year!
-castlan
In Unix, there is the concept of an unprivileged user. Unfortunately this is not adequately reflected in implementation. There are poor attempts to emulate this functionality by having non-user "users" such as daemon, nobody, mailer, or creating a "user" with the name of the program. There is the unfortuante choice between large numbers of bogus users polluting the passwd file and needlessly inflating UIDs, or creating few overpriviledged daemon users that are as vulnerable as the buggiest program in use, which can be as bad as comprmising root, and the entire system. Even an "unprivileed user" still has priviledges, as it is a user nonetheless.
The HIRD actually recognizes that daemons should be unprivileged. There is no user, the UID is null. If a service is compromized, then the rest of the system is insulated, specifically because that service does not run as an "unprivileged user", or any kind of user whatsoever.
Sentence 1 is disputed. As for sentence 2, I agree: "Pure fucking genious."
-castlan
It looks and acts just like Debian because it is Debian.
There seems to be much confusion in the philosophical, technical, and intangible Free Software world, I wonder why?
Debian is an operating system, that is an interface between the user and underlying hardware. If you will pretend with me that MS Wordpad is a reasonable word processor, then there is no reason to have to buy any other software for a basicly functional system. In this context, you can understand why MS had a valid reason to consider Internet Explorer an integral part of Windows... because the Web became significant. Earlier, MacOS included MacWrite, making WYSIWYG word-processing a significant part of the "operating System"... you get it now.
The Kernel isn't important to the OS, other than that there is something interfacing the higher level systems to the low level hardware - consider Windows NT 4.0 and Windows 95. They have the same basic userland minus a few changes, even though the underlying systems are completely different, i.e. a 32 bit microkernel in NT versus an 8 bit monolithic kernel in 95. Both have 16 bit Windows components integrated.
Likewise, Debian is a consistent operating system... namely, an incarnation of the GNU operating system. This GNU operating system is the realization of the GNU project, an OS that you can share freely with your friends without worrying about any corporations taking away that right.
But Debian is Linux! Right? No, Debian uses Linux. Debian GNU/Linux and Debian GNU/Hurd are both GNU, with Debian policy and integrated management utilities. There are slight differences in the userland, major changes in the underlying system... but you don't directly use "Linux".
Yes, that also means that RedHat is GNU.
While Redhat uses Linux, that doesn't mean that RedHat "is" Linux. But for the sake of Redhat's marketshare, they are willing to ignore that fact. Wall Street doesn't care that "Guh-new" wants "hackers" to be "Free", or even that it is a clever little recursive acronym. They care that "Linux" is recognizable for investors of software developers, like "dot-com" and "information superhighway". Linux sounds cool, money is cool, that's why were here, put it on the label.
If you are are using Windows NT, you aren't using the underlying hardware... the HAL, the microkernel components... at the lowest level most users see, your interface is the command interpreter. Usually you use the Explorer.exe interface. With Win 95, without the underlying components, the lowest you'll see is still the command.com text interface, ot the Explorer GUI.
If you are using a GNU (GNU/Linux) distribution, you aren't using your computer's internal hardware, or the Linux Kernel. If would be very uncomfortable to try using Linux without at least a BASH interface running atop, to accept input from you the mere user.
The issue isn't that of using the Hurd instead of Debian, Debian will use the Hurd as well as Linux. The issue is that of using The Hurd instead of Linux in your Debian system. Theoretically, the difference can be compared to using Win NT 4.0 instead of Win 95. That is, poorer hardware support, somewhat less simple subsystem configuration, but the promise of a microkernel proving to be more robust than a monolithic kernel like Linux.
-castlan
More significantly, and more exclusively, is the fact that DOS runs on pre-386 computers. Linux does not, not even netBSD will do that.
DOS will run with significantly less than 5 Megs of RAM, Linux tends to have major issues develop somewhere in the range between 3-5 Megs. Of course you might be able to counter that Linux has no trouble accessing over 640K. Touche'.
Well, how about boot time? A DOS floppy boots faster than a Linux floppy. (Not even GNU, just Linux kernel on a floppy). And the shutdown sequence tends to be significantly shorter.
Ohh! Best of all, Much like OpenBSD, DOS is "secure by default". No remote root exploit in the default configuration in over _20_ years! Beat that, you Canadian mountain biker!
Do I have a point? Moderation speaks louder than words! But if you don't have mod points, a reply will suffice.
-castlan
I would have say that "too good" was a poor choice of words, but the sentiment was correct. Perhaps "ahead of their time" is more accurate.
Sgi tends to be ahead of their time, which can be a good thing in their standard market of high end machines, but disasterous in the commodity world of ia32 PCs.
That they decided to "mess with the voltages for no apparent reason" is understandable unless you are comming from the commodity PC world. Standard x86 processors were all depended on 5V connections. Later, to aid in effeciency and higher clock speeds, they were reduced to 3.3V. You may remember the trouble with "Overdrive" enabled motherboards that were intended to be Pentium compatible before the Pentium part was available. By the time Pentiums were common, they used 3.3V, and so did their motherboards. Overdrive MBs needed to buy specific Overdrive CPUs that ran at 5V.
Well, as part of the PCI2.1 spec, there can be "2x" 66MHz connections, as well as 64 bit as opposed to the "standard" 32 bit connections. PCI boards need to be keyed to fit in the properly keyed PCI slots... there can be Universal cards that work at either 5V or 3.3V connections. Unfortunately for the 320 and 540, commodity low PCI cards didn't yet have enough reason to put out 3.3v wide or double speed compliant PCI cards. From SGI's end of the spectrum, the more performant cards were already standard, as they were necessary for e.g. gigabit ethernet, FDDI and other technologies in wide use by SGI consumers.
I've never heard anything like what you describe with USB... but I can't discount it outright because at the time I wasn't aware of very many USB consumer devices available on the market yet. But as for "firewire" ieee standard, SGI was again ahead of their time. They wanted the cutting edge connector on their hardware, but unfortunately the machine shipped before the standard was formalized, so there were inoperative ports on the visual workstations. If you needed those ports for digital video, then they would have shipped you the (high performance) pci cards for free.
As for the proprietary RAM, it was a shame that it was so expensive. But, it was sweet, and still nothing to sneeze at to have a system with 2 gigs of RAM. And though most pc lusers (like myself) still don't need such high performance ECC ram, it was a UMA system, meaning you could tell NT that you would like to allocate a chunk of it to display hardware. To date I'm not aware of NVidia shipping anything capable of 512 Megs of video ram. Having the Graphics hardware as tightly integrated into the system meant that it was capable of some impressive throughput, much like the O2. Unfortunately, tying yourself that thouroughly into your prediction of the future can be problematic, especially in the commodity technology arena when the main competetor is comprised of many of your own ex-engineers. No amount of RAM will make up for the lack of Transform and Lighting hardware for real time rendering, and they should have put more of their Reality Engine tech into the 320 and 540 Visual workstation. That would have made their much more profitable O2 Visual workstation obsolete, and so they crippled the x86 Visual workstation line. Too bad they didn't integrate (at least one) AGP slot, which at 1x didn't have to be much more difficult than a standard 2x PCI slot.
They gave up on it with their later line of 230 Visual Workstations, which cooperated with the commodity vendors NVidia by using commodiry motherboards.
But one thing that they got faulted for, more than any other, should have generated MUCH praise. That "seriously weird boot sequence" is something I'm dying for today, as It would make booting Linux much better unified across different platforms. SGI's GUI PROM bootloader is infinitely superior to the common pc's archaic and proprietary BIOS. As you may recall, the BIOS was IBM proprietary. While Compaq was able to reverse engineer, it is still the same crufty inflexible system that we started out with, virtually unchanged from 1980. Not because it was so good, but because it was so difficult to hack around and still be backwards compatible with the "IBM PC". Consider such nonsense as IRQs and CHS. IRQs got hacked up to 15, still not good enough, so there are elaborate IRQ sharing schemes in place... lets hope you don't need more expansion then that will allow. As for CHS, nobody needs more than 500 MB of disk, right? oh, well just invent an elaborate translation scheme where each subsystem thinks that any given disk block is located in a different place... that will give 2 Gigs. Oh, that can be expanded too, just as long as you don't need to boot from it.
Lilo is far from the ideal Linux booter. Grub is much more flexible, but it's no OpenFirmware. Both Apple and Sun have this far superior facility for bootstrapping their system. SGIs elegant PROM made LILO apparent as the crufty hack it was; you could use your mouse to navigate, or you could use a remote console via serial port, you specify where the Linux Kernel was located, or NT would specify it for you during the install. No other bootloader, not even GRUB, can boot both NT and Linux.
Yes, SGI screwed up with locking in the graphics hardware, which was summarily leapfrogged by their own T&L tech embodied in NVidia. They overestimated PCI card makers and jumped the gun connectivity wise, be it PCI2.1, LVD SCSI, openLVI or "firewire", the opportunity to free us from our cursed "established market" standard PC BIOS should have been a breath of fresh air, and was hardly an attempt to screw us over. It is a loss I mourn at least once month as I wait, still hoping that GRUB, or openBIOS, or something better comes along with which to boot my system.
Maybe I should just get more money and buy a Mac. Or even more money for a Sun. Or I could hit the lottery and buy a post-Octane 2 Unix workstation. Guess I'll just suck it up with El-torito, GRUB, and LBA addressing.
SGI already did the co-operation thing with NVidia... that's where NVidia's binary XFree drivers came from. That is also how much of the DRI structuring for Xfree86 4.x came about.
As Temkin said, NVidia was largely composed of former SGI people, which explains why the NVidia graphics chips are so perfomant. In fact, the hardware was too good... much of the technology violated SGI patents.
As part of the resolution, they teamed up for the SGI 230 and 540 series of "Visual Workstations" which were basically standard ia32 PCs with professional higher end versions of the geForce called Quadro. They got the best silicon, and what was left was user for the consumer NVidia cards.
The Octane 2 has "much more powerful chips at much lower prices" as a result, it is basically an NVidia graphics chip welded to the Octane's crossbar architecture. Of course, when you talk about SGI/MIPS workstations, "lower prices" is still a relative term.
So your "what if" questions got answered... commodity hardware running free GNU variants supporting free accelerated X11 capable of running immersive 3d environments worthy of Classic SGI demos like Performer Perfly, or even Quake!
-castlan
DoH!!!
Now I RELLY hope that my post was helpful.
What's wrong with R5? Why do you prefer R4?
Or maybe you aren't aware that there is a R5 release available for PPC. The BeOS R5 Pro CD contains BeOS for both i586+ and PPC 603x/604x PCI motherboards. 3 partitions, one BeFS PPC, one BeFS x86, and one Universally readable iso9660 partition cantain the entire system, including source code for the GNU utilites and boot loader executables.
-castlan
I would like to know if you have a response for this, but moderator points force anonymity. Hope that you find this helpful.
That sounds like you are taling about the standard UNIX encryption library, which is visibly used for the standard UNIX passwd command. You cannot determine what the password is by performing matematical transformations on the /etc/passwd contents.
/etc/passwd, then there is a match.
/etc/passwd.
Instead, we use passwd to perform the transormations on what we suspect the user used for the password. If the output is the same as the previously encypted password in
To exploit this, you passwd-encrypt a dictionary of words, and then see if any of the output matches an entry in
Or, you could just capture the traffic now, and run a modern cracker against it. By the time quantum-computing technology becomes consumer-level technology, it is likely that anything you have a significant interest in will have been cracked. Just don't ever turn off your computer.
-castlan
To venture out on a limb and make a statement that I should not make, being that I am crytographically challenged:
Why not just use a 1 bit key? Anybody that knows how to crack your message can get the job done anyway, but it would still keep your content private to the general public, with minimal CPU expenditure. I an ignorantly guessing that XORing your data qualifies?
Actually, all of the above is bullshit. I just wanted to be a nudge and point out some possible exceptions to the statements made in your signature.
It is very probable that somebody got fired at SGI for choosing Microsoft, probably each time it happened (NT4-MIPS with ARC booting, SGI Visual Workstations using NT4-x86 with ARC booting...) It's likely the decision to base the AOL web-brower on IE wasn't highly rewarded either.
I'm also sure that many fools have been exposed by trying to run a Linux based OS on a Token ring network. Those involved in the OpenBSD project would probably mave some interesting alternatives to praise ready for any who would suggest that they host their web site on RedHat Boxen.
I must really be itching for some negative mod points here... Perhaps I should have encrypted this message before posting.
-castlan
Theoretically there is no reason why there shouldn't be infinitely many distinct distributions of Linux. My having an unrelated distro really shouldn't have any tangible effect on your distro. Most of the concievable negative effects are negated by following the LSB, if not the FHS. The only significant problem I see is that of a newbie being overwhelmed by their initial choice, if they don't have any criteria to choose their distribution by.
This is why is would be good to have a central resource that has a taxonomy of Linux distributions, along with user rankings of different aspects of the various versions of differing distros. That way, by answering a few simple questions a newbie could be guided to the highest quality distro that fulfills their criterion. I know of at least one web site that has a compilation of the various distros available, but I am not certain of any that have a useful ranking.
Now I don't see why you allow for the choice between Mandrake and Red Hat. Progeny is at least as different from Debian proper as Mandrake is from Redhat. The most obvious difference in Mandrake is that during the standard RedHat install, it switches over to a much nicer graphical install that had a much more robust Hardware autodetection the last time I tried it. If you can point out some more distinctions between Mandrake and RedHat, then Maybe you have a valid point. As is, your bias is most unfortunate... RedHat and Mandrake add more to the distro glut due to overlap than Turbolinux does.
Progeny also has a nice GUI installer not available to Debian proper. I understand that Mandrake now includes Grub as standard over Lilo while RedHat doesn't... Progeny used GRUB from day one. And it was quite nice to have Progeny development seperate from standard Debian, as it allowed such packages as GnuCash with very complex dependancies to be prioritized for the commericial Progeny, while it is just about unusable in any standard Debian distro. One of the important qualities of Debian is that it does not have any kind of externally set release schedule, which is a large part of the reason the stability of the Debian distro far outshines the other distributions.
You seem to not understand The Debian system very well, which is very unfortunate. It is not inherently more complex, it just seems evident that you have never given it a real chance. Apt does not have some magical technology that far surpasses all other forms of package management. The advantage lies in the policy, and politics, which are inherently slow moving. The red tape of policy, while annoying if you have a political agenda, is great if you want a stable system. Apt doesn't isolate the apps, Apt just applies the rules policy dictates.
FYI, you can have the Stable distro and run the latest apache if you like. The most "stable" way would be to compile your own apache package, with proper dependencies set, and then install that. If you just want to install the premade package, you can do that as well... but it might require you to update some of your libraries to newer, less "stable" versions if the apache dependancies demande it.
Again, Debian development should not be "sped up" in the way you seem to suggest, which would imply relaxing the Debian policies. Those policies are the reason why Debian will remain the best long term solution to an operating system. The problem is when you need something "now" that might not be available yet... The best solution IMHO was the one Progeny pursued, basing their own distro off of the Debian standard sources. Then, you could "speed up" development for thiose components you consider most important as much as you like without hurting the rest of the Debian project. On the way, contribute your improvements back to Debian so that they can (over time) integrate your enhancements into the standard debian syste, (which spans many architecures.... there is a good reason why things much not move too fast). I definitely think that Progeny development has been cut short prematurely, and it is most unfortunate.
The existence of Progeny has at least as much justification as that of Mandrake. Being a "geek" is not the only reason to want a better system, and Progeny is still the best place for a newbie to start in my mind, as it is the easiest path to the stability and quality of a Debian system. The only reason I can see for Red Hat is if it is already company policy, because of long term support contracts already paid for. In this case, there is no reason to have Mandrake as the "easier Red Hat" as the support contracts likely won't cover the distinct distribution. If you are looking for a new support contract, I would still suggest Progeny, as they provide support for ANY Debian distro, including Progeny Debian. SuSE and TurboLinux are still valuable in Germany and Japan, respectively, though Debian is making much headway in those areanas as well.
Slackware is good if you already know it, and for current slackware users I would not recommend switching distros if it has everything you need. If you want to have a very "Unixy" system, as opposed to the fluff that Linux distros provide, Slackware is a good choice. I feel you are right in this aspect when it comes to "the geekier crowd", or those who are staunch in having a Unix that still feels like Unix. If you aren't a current Slack user, and you want a Unix system for the sake of Unix purity, especially for development, I'd probably suggest that you go with one of the BSDs instead. There are some that say that the *BSD Ports/Packages system is better than Apt... but I can' comment on that as of yet. For standard development I'd probably suggest NetBSD, unless you are directly on the internet, or have a multi-proc system.
Oh, BTW, I choose Debian, and for me the installer was a big deal. If you've never tried it, the Debian-cd image maker was an unpleasant bitch, especially behind my company's firewall. Having a cable-modem and boot floppies is much nicer, but I didn't have that luxury when I first tried Debian. I remember a tear of joy at finding the progeny ISO on their website when they first came out... I way anything but malcontent at that point.
While RPM and dpkg databases are very sophisticated compared to Windows Uninstall or Installshield, they are hardly all-knowing. Rather than tracking files, they know the files they own, that they installed.
/etc that may or may not be purged.
In Debian, each file can only have one owner. If more than one package claims to own a file, than an error is flagged. But that doesn't necessarily mean that every file on the system is owned. Even if you don't count files extracted from the base.tar during older installs, there are many files that are generated during or after installing a package. Any file generated by an install time script instead of extracted from the compressed package is not claimed by any package. The uninstall scripts still have to remove dirctories specific to their application if they want to try to fully remove all traces of the app. Mind you, this is in addition to configuration files in
Windows Add/remove justs keeps track of files it explicitly installed. It then gives you the option to remove those specific files (or sometimes upgrade them). Debian is significantly more sophisticated in that it keeps track of dependancies, but it has yet to manage every non-user file in the system. So far, their stop-gap measure to manage this mess is the package cruft, which helps to scan the system for unclaimed files.
So, even with package management as sophisicated as Debian's, in the end the administrator still has to manage the files. Package management cannot supplant proper filesystem layout (...yet).
How in the hell was the parent moderated up to 3?
/opt as part of a solution, for example. Slack is most unlike Red Hat and its many derivatives.
/usr/local useful. Perhaps the solution for you would involve /usr/local/apps, /usr/local/utils, etc. (/usr/local/etc? :P) Everything you compiled belongs within /usr/local/ if you choose to adhere to the guidelines set out in the FHS. Within that framework, you can organize by function, or whatever else you fancy.
/usr/internet or /usr/editor exists in the /etc/alternatives directory. Try "man update-alternatives". While /etc/alternatives/infobrowser exists for .html help pages, perhaps there sould be an /etc/alternatives/webbrowser entry.
/usr/home, provided all PATH environments are properly configured. Keeping personal files scattered throughout /bin directories is a better way to "sure-fire confusion".
/bin directories, try browsing at a high moderator number, and see a range from:
/opt, with appropriate links in /usr/bin. For systems w/package management, make that /usr/local/bin as in #2595732
/usr/bin, which calls the appropriate executable depending on its flag;#2598189
/bin subdirectory in the /usr hierarchy. ##2595676
I have seen multiple solutions posted while browsing at moderator level 3. Am I going to have to start browsing at 4 now?
There is no standard in Windows like the FHS, only Microsofts latest guidelines which don't to my knowledge address proper Start menu behaivor. Every app I know that tries to put a shortcut directly in the Start menu gives an option between having it in the start menu, on the desktop, and in the IE launch bar. The exception I've seen is AOL launcher, primarily because it is preinstalled. I will agree that the Windows Start Menu needs a coherent management scheme published.
Limiting your experience to Red Hat and Mandrake and then proclaiming anything about "everyone's guily" is silly. Mandrake is all but another distribution of Red Hat. Might as well make a blanket statement after using Debian and Progeny. There are many statements praising recent Slackware versions for using
The FSS is not intended to make organizing one's hard drive any easier, but to make distributions less likely to interfere with your organization. That is what makes
As for the distribution system, I don't see that such arbitrary classification is as useful for filesystem layout as grouping by the application's title. There are better places for those distinctions, like in the "Start Menu". In Windows, ideally, everything is installed into its own directory as much as possible, while the Start Menu is grouped more by user functionality.
In response to the anonymous coward of message #2596088, in Debian, the best place for such things as
/home is far from irrelevant. It is the only place where non-sysadmin related files should reside, unless they are being served over a network or removable media. Any non-root user should never have reason to leave
The best way to have an organized hard disk is to have a reasonable set of guidelines you follow on filesystem layout. After that, just follow them! The best way to fight entropy, is of course, to do something useful! After you die, then you should emprace entropy. I suspect that the rhetoric of apathy in these two statements garnered your 2 "insightful" moderations. Give me a break, learn some discipline and organization.
----
As to the solutions that "nobody" has offered to this problem of clutered and unwieldly
1. No problem, who cares what the Filesystem looks like when the Package manager suits your needs;
2. Use one of the automated soltions listed at the Opt Depot like GNU STOW;
3. Keep all "applications" in subirectories in
4. Keep only one symlink for any "application suite" in
5. My least favorite - expand your PATH variable to include every
Note to self:
##2596072 gives a reference and addresses the shortcoming of current Debian Package Management - concurrent divergent versions of applications.
Try Debian instead.
$ apt-cache search ldap2
libldap2 - OpenLDAP libraries.
libldap2-dev - OpenLDAP development libraries.
libopenldap1 - OpenLDAP libraries (obsoleted by libldap2).
$ apt-cache show libldap2
Package: libldap2
Priority: important
Section: libs
Installed-Size: 430
Maintainer: Wichert Akkerman
Architecture: i386
Source: openldap2
Version: 2.0.14-1
Replaces: libopenldap-runtime
Depends: libc6 (>= 2.2.3-7), libsasl7
Filename: pool/main/o/openldap2/libldap2_2.0.14-1_i386.deb
Size: 174132
MD5sum: 2a3b44f7c257d854e0a700624739e9ed
Description: OpenLDAP libraries.
These are the run-time libraries for the OpenLDAP (Lightweight Directory
Access Protocol) servers and clients.
Somewhat less than a full generation old in the Debian camp. OpenSSL is at least 0.9.6. Pine has to be built from source so as to not violate its copyright, but Debian provides the source and Debian diffs in their package manager all set to build. As for installing libraries, it works out fine if you use the package manager to do it. If you can build the libraries from source, then you are competent enough to make a package from that very same source. If there is a problem, then using the equivs package can convince your system that dependancies are met.
As for having the Package Management system look around your system to satisfy dependancies, perhaps Red Hat should do that. Debian dependancies are more sophisticated that "is that file present?" They need version information as well, which can be troublesome if you consider the variations possible with open source. Debian can only verify binaries which it generates. The best way to do that is by downloading directly from their archive.
Perhaps you mean to say
"underfuntional bloated web interfaces are your enemy"
or
"superfluous GUIs suck, CLIs are your friend"
or something along those lines. How about "libNEWT is your friend"?
I still support "SSH is your friend" despite it not being the point you seem to have intended, unless you meant it in reference to Web management consoles exhibiting great suckage compared to more straightforward textual interfaces. Then perhaps the SSH statement fits.
WRT port services, wouldn't netcat be a better answer than telnet? The way I see it, "telnet is your occasionally useful historian" for legacy purposes only.