Are the fields different? They appear to be identical between Solaris 2.6 and Redhat 6.0...
But you're right about the encryption differences - I'd forgotten about that when I posted before.
Does Slackware use PAM these days? I guess the differences you mentioned are down to the MD5 encryption scheme, which *could* be disabled (via/etc/pam.d/login) for compatibility.
Security-wise, though, it would be better to keep it active and perhaps generate new passwords for each user. Cracking's an option, but then those users who've actually chosen secure passwords suffer, which is a bit unfair:-)
I'm guessing you're referring to SunOS 5.x (Solaris 2.x/Solaris 7) here, rather than SunOS 4. To be pendantic, SunOS actually refers to the kernel, Solaris is the distribution, as it were.
Anyway, Solaris does not support usernames of greater than 8 characters, although it may happen to work at times. In particular, try using useradd to add a user of more than 8 characters - it won't work. I also recall that even if you add users of more than 8 characters by editing the password/shadow file directly, problems can arise: I remember passwd crashing on me in this situation once.
In short, don't do it, on Solaris or Linux:-)
As far shadow file compatibility, yes, they should be fully compatible. I haven't verified this empirically, but according to the manual pages on Solaris 2.6 and Red Hat 6.0, the order and meaning of the shadow fields is identical.
I can't speak for Slackware, I don't use it, but I would imagine it uses the same shadow format as Red Hat.
Not at all. Operating a gear level doesn't take much in the way of strength or dexterity - it's something a right-handed person can easily do with their left hand.
Well, you don't have to know the IRQ of your sound card. Until, of course, Windows decides it would be nice to set your sound card to the same IRQ as your network card. Then your sound stops working, your network stops working, and all Windows has to say is "System has detected a hardware conflict.".
Oh, I'm glad it's not just me, in a twisted sort of way:-)
Windows 98: the only OS that uninstalls your GLIDE drivers when you upgrade your soundcard drivers.
Windows 98: the only OS that installs the same network card driver three times, and then complains about conflicts.
Yes, the above have happened to me. The network card incident followed a hardware failure. In Linux, I replaced the card, booted, and all was well. It took (count em) 8 reboots to finally persuade Windows that a new, working, card was actually present.
This is, apparently, ease of use in action.
(By the way, I didn't need to know my modem COM port the last time I installed Linux either)
AIUI, If they distributed a product with a Linux kernel, they would have to make the source available for no charge other than handling costs, modified or not. Now, here's where I'm not so sure: is it enough for them just to say "get it from www.kernel.org"?
But this is all pretty academic anyway, since it looks like this iToaster doesn't run Linux.
Oh, I have done some digging, and come up with several different ways of setting proxies, all of which involve editing prefs50.js, and none of which work.
Not wanting to moan, but something as fundamental as this should at least be mentioned in the release notes, even if just to say "this doesn't work".
I appreciate it's alpha, so I'm not desperately concerned about speed in that respect.
What bothers me is the several other articles which claim it's blindingly fast - on this machine it's quite the opposite. It's a standard Red Hat 6.0 machine, P2-266, 128MB RAM. Communicator 4.6 is pretty zippy.
So, am I missing something, or is everyone else running on P3-550's?
And is there truly no way of setting up a proxy host? I've looked, and I can't find one.
...because it feels about an order of magnitude slower than Communicator 4.6 on this Linux box.
Coupled with the fact the Proxy preferences dialog doesn't work (try setting a proxy manually), and the (IMHO) extreme ugliness of the whole browser, and I'm somewhat less than excited.
I currently have a Matrox Millenium G200 (great 2D card), and a rather old Voodoo 1 for the 3D stuff. I want to upgrade my 3D capabilities soon, so I'll be looking a new card. In light of recent events, 3DFX is no longer an option:-)
Now, both the G200 and the nVidia TNT2 are 2D/3D combos, right? From what I've read, the TNT2 is a much better 3D card than the G200, is that the case?
Sooo, should I buy a TNT2 and get rid of the G200? Or is the G200 going to be sufficient? Let's assume performance is more important than cost for now, which should I go for?
Speaking as someone who has worked for an ISP, I'm going to disagree with you. SSH/Telnet access is BY NO MEANS a substitute for console access (although it's obviously useful in it's own right).
We had a couple of machines located in London, about 60 miles from our office, and having console access via a terminal server saved several trips to London - and if you've ever tried to drive in London, you'll appreciate how important that is:-)
Of course, those machines were Sun boxes, where that sort of thing is trivial. But this new Phoenix BIOS sounds like it might the answer to a lot of prayers.
Oh well, perhaps I just miss the old days curled up in the green glow of a WYSE term hacking useless C progs for shits and giggles. Those where the days!
Ooh yes. Though I'm sure I remember them being amber. I also remember them having the nicest keyboards I've ever used.
Their current game is Everquest, a very addictive multi-user first-person RPG.
Particularly bad for those of us in Europe (see that other story today:-) since it's online only.
If you want to keep a life, don't start playing this game. Or at least, put an alarm clock beside your computer so that you don't suddenly realise you're supposed to be getting up for work in half-an-hour's time.
Drawing anti-aliased text takes signficantly more resources than plain text.
Not everyone needs, or even wants, anti-aliased text. For example, at very small point size, anti-aliasing tends to make things worse, not better.
Therefore, anti-aliased text must be an option, and not ubiquitous.
So, it would have to be implemented as an extension. It's not good enough to globally change the semantics of XDraw{Image}String{16}, and expect everyone to live with the consequences - that truly would be a backwards compatibility nightmare. And while it might be nice in DTP applications, or in Netscape, I definitely don't want it in every terminal window I use.
As an extension, obviously, existing clients wouldn't take advantage of it. But it's the only reasonable approach I can see. With XFree86 4.0's dynamically loadable modules, it may become reasonably easy to simply plug in an XAntiAliasedText extension. If it works well enough, software will come to support it.
On the other hand, the article said that the only components being opensourced were the 64-bit filesystem and the journaling support. I suspect this means that the volume manager won't be part of the package.
Still, what's there is nothing to be sneezed at. Kudos to SGI.
Re:IPv6 never going to happen? I think it will
on
IP Address Shortage
·
· Score: 1
Comparing IP address space to real estate is a poor analogy. While simply creating real estate out of thin air is impossible, creating a larger IP address space is quite possible (if non-trivial:-)
Speaking as someone who has worked for an ISP, I think IPV6 will happen. It'll be a long time before IPV4 is phased out, I agree, but IPV6 is by no means dead in the water.
Remember, IPV6 involves many more improvements over IPV4 than just a larger address space (though that is one of the most significant). We'll get goodies like:
Much more efficient routing (people have already mentioned that in this thread).
Extensible address headers will also make life much easier for routers
Security - authentication and encryption in the IP layer, where they belong.
Mobility, and address autoconfiguration - an IPV6-enabled device can autoconfigure itself whenever it's plugged in at a new location.
Quality of service - IPV4 has this, but IPV6 improves on it. Someone mentioned that IPV6 wouldn't be much good for real-time applications - it will be.
Suits and ISP's are seeing the value of a greatly improved technology - to suggest that they want to keep IPV4 simply because they can inflate address costs is crazy. It ain't so.
It's very obvious you don't know how RAID 5 works.
Oh, save the condescending attitude. I work with RAID systems every day. Don't tell me I don't know my job.
You conveniently ignored what I said, so try to pay attention this time: to write a RAID 5 partition you must reread parity information from the disk, unless you are doing a Full-Stripe-Write; you need to write (ndisks -1 ) * stripe_size bytes of data in one operation to avoid the performance hit. Oh, and that data has to aligned on a stripe boundary, too.
Otherwise, you end up doing either a Read-Modify-Write or a Reconstruct-Write, and that's expensive.
Now are you going to tell Veritas that they don't understand RAID either?
First, yes it's an XOR (at least you got that right). However, reading takes just over x+1/x amount the time of reading from a RAID 1 set. Just over being the time it takes to do an XOR and comparison.
You're wrong there, too, by the way. Reading a RAID-5 volume is just as quick as reading RAID-0. No XOR'ing needs to be done when you read. And you have the cheek to accuse me of not understanding RAID-5?
Yes, you're right when you say RAID 5 is striped parity - that's what I said too. But you're wrong if you think you're going to get reasonable write performance from RAID 5.
Think about it for a minute.
Every time you write a block on a RAID 5 volume, you have to recalculate the parity for that block. That means you have to reread the parity stripe, and XOR the information before you can write the block.
Hardware RAID helps with the XOR process, but it doesn't help with rereading the disk.
If you have hardware RAID like these servers, then you're not going to notice anything with write speed.
If you're doing a lot of writes, you very definitely will notice decreased performance compared with mirroring.
RAID 0 by itself provides no redundancy at all, it just combines several physical disks into one larger virtual disk. It can improve performance, especially if striped properly. In fact, RAID 0 on its own reduces redundancy - if one disk goes, you lose the entire volume.
RAID 1 is mirroring, which gives you redundancy, at the cost of extra storage requirements - you need two (or more) 1GB disks to get a 1GB mirrored volume. Mirroring can slightly improve read performance, and slightly disimprove write performance (everything has to be written twice, or more).
A common setup is RAID 0+1, striping and mirroring in combination.
RAID 5 is distributed parity - another form of redundancy. You can combine, say, 4 disks into one volume, with 3 disks worth of data and 1 disk worth of parity information.
RAID 5 is cheaper than 0+1, since it requires less storage. Read performance is fairly good, but here's the catch: write performance is lousy. If it's a write-intensive filesystem, don't use RAID 5.
E + GNOME ? Noooooo.....
on
Red Hat 6.0
·
· Score: 1
I've gotta agree here. I've been trying to keep an open mind on KDE vs. GNOME, but the truth is, KDE's a long long way ahead right now.
The problem with GNOME (and I do keep trying new versions) is its speed and memory consumption. Instability's still a problem, though definitely improving.
With anything other than the default Gtk theme, and with E running as well, performance drops through the floor, and memory consumption rises dramatically. An X server using 64MB of RAM, 32MB resident? No thank you!
Things are somewhat better with IceWM rather than E, but GNOME is still way too slow to be usable.
I'll probably get flamed on two counts here:
1) Get a faster machine? This is a PII-400 with a Millenium G200 graphics card. If that's not fast enough to run GNOME, then I won't run GNOME, simple as that.
2) Don't use themes or E. Fair enough, but since themes are touted so much as a super-cool GNOME feature, and the default Gtk look is well, plain, that's a pretty ridiculous argument too.
I can't help feeling that GNOME has been paying far too much attention to cutesy looks, and neglecting those little details like performance, stability and functionality.
Goddamned runlevels./etc/rc.d is WAY too complicated for any purpose I can realistically see people desiring... and it is nontrivial for administrators to jump between distributions on different machines. The Slakware scheme was more than sufficient. Thankfully, VAResearch includes a cheat-sheet with all of their servers, making the transition easier if you have the means.
I guess this is a bit of a religious issue, but I really believe that Red Hat's (the SYSV) way is the Right Way To Do It.
One script per service makes everything much, much easier. Adding a new service? Just drop a script for it in/etc/rc.d/init.d and link it to the/etc/rc.d/rcN.d, where N is the runlevel you want to stop or start it.
Removing a service? Remove the init scripts. Done. This is much much easier than the BSD way.
The SYSV way also makes it much easier to write service administration programs, like Red Hat's chkconfig, or KDE's ksysv.
It really does make sense. I've yet to hear a single practical reason why the BSD way is better - it just doesn't have a single advantage over the SYSV way that I can see.
It's just proof sterotypes are bad.
on
UNIX for Moms
·
· Score: 1
I think you're pretty much right there. As a prime example:
I was talking to my mother a couple of weeks ago about what I do, and why I don't like Windows.
Basically, my mum isn't interested in computers. As far as she's concerned, a computer is just a tool to get a job done. That's not to say she's ignorant about computers or afraid of them, but her personal interest stretches as far as running an accounting package where she works.
(Oh, and playing the odd game of Scrabble on a old ZX Spectrum from when I was still living at home, but that's beside the point:-)
But anyway, she doesn't know what Unix is, she's only ever used DOS and Windows. And she doesn't like Windows. It's slower, it's less stable, and there's too much graphical fluff which just distracts her from the job in hand. DOS was easier and quicker from her point of view.
By those criteria, she'd be happy with a command-line Linux shell and a Unix version of whatever accounting package she uses (a fairly obscure bespoke package, I believe). She'd dislike KDE (too much graphical fluff), and she'd absolutely loathe GNOME (waaay over the top, and slow with it).
In this mad rush to make Linux "mom-friendly", how many people have actually spoken to the very people they're trying to accomodate?
Slashdot Mirror
Are the fields different? They appear to be identical between Solaris 2.6 and Redhat 6.0...
/etc/pam.d/login) for compatibility.
:-)
But you're right about the encryption differences - I'd forgotten about that when I posted before.
Does Slackware use PAM these days? I guess the differences you mentioned are down to the MD5 encryption scheme, which *could* be disabled (via
Security-wise, though, it would be better to keep it active and perhaps generate new passwords for each user. Cracking's an option, but then those users who've actually chosen secure passwords suffer, which is a bit unfair
Anyway, Solaris does not support usernames of greater than 8 characters, although it may happen to work at times. In particular, try using useradd to add a user of more than 8 characters - it won't work. I also recall that even if you add users of more than 8 characters by editing the password/shadow file directly, problems can arise: I remember passwd crashing on me in this situation once.
In short, don't do it, on Solaris or Linux :-)
As far shadow file compatibility, yes, they should be fully compatible. I haven't verified this empirically, but according to the manual pages on Solaris 2.6 and Red Hat 6.0, the order and meaning of the shadow fields is identical.
I can't speak for Slackware, I don't use it, but I would imagine it uses the same shadow format as Red Hat.
s/level/lever/
I'll use the Preview button next time...
Not at all. Operating a gear level doesn't take much in the way of strength or dexterity - it's something a right-handed person can easily do with their left hand.
Oh, I'm glad it's not just me, in a twisted sort of way :-)
Windows 98: the only OS that uninstalls your GLIDE drivers when you upgrade your soundcard drivers.
Windows 98: the only OS that installs the same network card driver three times, and then complains about conflicts.
Yes, the above have happened to me. The network card incident followed a hardware failure. In Linux, I replaced the card, booted, and all was well. It took (count em) 8 reboots to finally persuade Windows that a new, working, card was actually present.
This is, apparently, ease of use in action.
(By the way, I didn't need to know my modem COM port the last time I installed Linux either)
AIUI, If they distributed a product with a Linux kernel, they would have to make the source available for no charge other than handling costs, modified or not. Now, here's where I'm not so sure: is it enough for them just to say "get it from www.kernel.org"?
But this is all pretty academic anyway, since it looks like this iToaster doesn't run Linux.
Oh, I have done some digging, and come up with several different ways of setting proxies, all of which involve editing prefs50.js, and none of which work.
Not wanting to moan, but something as fundamental as this should at least be mentioned in the release notes, even if just to say "this doesn't work".
I appreciate it's alpha, so I'm not desperately concerned about speed in that respect.
What bothers me is the several other articles which claim it's blindingly fast - on this machine it's quite the opposite. It's a standard Red Hat 6.0 machine, P2-266, 128MB RAM. Communicator 4.6 is pretty zippy.
So, am I missing something, or is everyone else running on P3-550's?
And is there truly no way of setting up a proxy host? I've looked, and I can't find one.
...because it feels about an order of magnitude slower than Communicator 4.6 on this Linux box.
Coupled with the fact the Proxy preferences dialog doesn't work (try setting a proxy manually), and the (IMHO) extreme ugliness of the whole browser, and I'm somewhat less than excited.
I have a question to add:
:-)
I currently have a Matrox Millenium G200 (great 2D card), and a rather old Voodoo 1 for the 3D stuff. I want to upgrade my 3D capabilities soon, so I'll be looking a new card. In light of recent events, 3DFX is no longer an option
Now, both the G200 and the nVidia TNT2 are 2D/3D combos, right? From what I've read, the TNT2 is a much better 3D card than the G200, is that the case?
Sooo, should I buy a TNT2 and get rid of the G200? Or is the G200 going to be sufficient? Let's assume performance is more important than cost for now, which should I go for?
Speaking as someone who has worked for an ISP, I'm going to disagree with you. SSH/Telnet access is BY NO MEANS a substitute for console access (although it's obviously useful in it's own right).
:-)
We had a couple of machines located in London, about 60 miles from our office, and having console access via a terminal server saved several trips to London - and if you've ever tried to drive in London, you'll appreciate how important that is
Of course, those machines were Sun boxes, where that sort of thing is trivial. But this new Phoenix BIOS sounds like it might the answer to a lot of prayers.
Ooh yes. Though I'm sure I remember them being amber. I also remember them having the nicest keyboards I've ever used.
Particularly bad for those of us in Europe (see that other story today :-) since it's online only.
If you want to keep a life, don't start playing this game. Or at least, put an alarm clock beside your computer so that you don't suddenly realise you're supposed to be getting up for work in half-an-hour's time.
So, it would have to be implemented as an extension. It's not good enough to globally change the semantics of XDraw{Image}String{16}, and expect everyone to live with the consequences - that truly would be a backwards compatibility nightmare. And while it might be nice in DTP applications, or in Netscape, I definitely don't want it in every terminal window I use.
As an extension, obviously, existing clients wouldn't take advantage of it. But it's the only reasonable approach I can see. With XFree86 4.0's dynamically loadable modules, it may become reasonably easy to simply plug in an XAntiAliasedText extension. If it works well enough, software will come to support it.
Here's hoping, anyway.
perldoc English and perldoc perlvar will tell you more.
After all, there is more than one way to do it :-)
On the other hand, the article said that the only components being opensourced were the 64-bit filesystem and the journaling support. I suspect this means that the volume manager won't be part of the package.
Still, what's there is nothing to be sneezed at. Kudos to SGI.
Speaking as someone who has worked for an ISP, I think IPV6 will happen. It'll be a long time before IPV4 is phased out, I agree, but IPV6 is by no means dead in the water.
Remember, IPV6 involves many more improvements over IPV4 than just a larger address space (though that is one of the most significant). We'll get goodies like:
Suits and ISP's are seeing the value of a greatly improved technology - to suggest that they want to keep IPV4 simply because they can inflate address costs is crazy. It ain't so.
This is true, though obviously depends on your CPU as well.
My P-II 400 with a Voodoo1 gets between 30-40 FPS on Linux (using the 3dfxgl minidriver).
I'd stop now, bkosse, if I were you. Have you noticed how every one is disagreeing with you?
Could be because everyone in this thread except you knows what they're talking about?
Oh, save the condescending attitude. I work with RAID systems every day. Don't tell me I don't know my job.
You conveniently ignored what I said, so try to pay attention this time: to write a RAID 5 partition you must reread parity information from the disk, unless you are doing a Full-Stripe-Write; you need to write (ndisks -1 ) * stripe_size bytes of data in one operation to avoid the performance hit. Oh, and that data has to aligned on a stripe boundary, too.
Otherwise, you end up doing either a Read-Modify-Write or a Reconstruct-Write, and that's expensive.
For write-intensive filesystems, don't use RAID-5
My source for this?
Now are you going to tell Veritas that they don't understand RAID either?
First, yes it's an XOR (at least you got that right). However, reading takes just over x+1/x amount the time of reading from a RAID 1 set. Just over being the time it takes to do an XOR and comparison.
You're wrong there, too, by the way. Reading a RAID-5 volume is just as quick as reading RAID-0. No XOR'ing needs to be done when you read. And you have the cheek to accuse me of not understanding RAID-5?
Think about it for a minute.
Every time you write a block on a RAID 5 volume, you have to recalculate the parity for that block. That means you have to reread the parity stripe, and XOR the information before you can write the block.
Hardware RAID helps with the XOR process, but it doesn't help with rereading the disk.
If you have hardware RAID like these servers, then you're not going to notice anything with write speed.
If you're doing a lot of writes, you very definitely will notice decreased performance compared with mirroring.
I think you've both got your RAID numbers confused. There's certainly nothing wrong with using RAID 1 on a server.
RAID 0 = concatenation/striping
RAID 1 = mirroring
RAID 5 = distributed parity
RAID 0 by itself provides no redundancy at all, it just combines several physical disks into one larger virtual disk. It can improve performance, especially if striped properly. In fact, RAID 0 on its own reduces redundancy - if one disk goes, you lose the entire volume.
RAID 1 is mirroring, which gives you redundancy, at the cost of extra storage requirements - you need two (or more) 1GB disks to get a 1GB mirrored volume. Mirroring can slightly improve read performance, and slightly disimprove write performance (everything has to be written twice, or more).
A common setup is RAID 0+1, striping and mirroring in combination.
RAID 5 is distributed parity - another form of redundancy. You can combine, say, 4 disks into one volume, with 3 disks worth of data and 1 disk worth of parity information.
RAID 5 is cheaper than 0+1, since it requires less storage. Read performance is fairly good, but here's the catch: write performance is lousy. If it's a write-intensive filesystem, don't use RAID 5.
I've gotta agree here. I've been trying to keep an open mind on KDE vs. GNOME, but the truth is, KDE's a long long way ahead right now.
:-)
The problem with GNOME (and I do keep trying new versions) is its speed and memory consumption. Instability's still a problem, though definitely improving.
With anything other than the default Gtk theme, and with E running as well, performance drops through the floor, and memory consumption rises dramatically. An X server using 64MB of RAM, 32MB resident? No thank you!
Things are somewhat better with IceWM rather than E, but GNOME is still way too slow to be usable.
I'll probably get flamed on two counts here:
1) Get a faster machine? This is a PII-400 with a Millenium G200 graphics card. If that's not fast enough to run GNOME, then I won't run GNOME, simple as that.
2) Don't use themes or E. Fair enough, but since themes are touted so much as a super-cool GNOME feature, and the default Gtk look is well, plain, that's a pretty ridiculous argument too.
I can't help feeling that GNOME has been paying far too much attention to cutesy looks, and neglecting those little details like performance, stability and functionality.
But it does look nice, I'll give it that
I guess this is a bit of a religious issue, but I really believe that Red Hat's (the SYSV) way is the Right Way To Do It.
One script per service makes everything much, much easier. Adding a new service? Just drop a script for it in /etc/rc.d/init.d and link it to the /etc/rc.d/rcN.d, where N is the runlevel you want to stop or start it.
Removing a service? Remove the init scripts. Done. This is much much easier than the BSD way.
The SYSV way also makes it much easier to write service administration programs, like Red Hat's chkconfig, or KDE's ksysv.
It really does make sense. I've yet to hear a single practical reason why the BSD way is better - it just doesn't have a single advantage over the SYSV way that I can see.
I think you're pretty much right there. As a prime example:
:-)
I was talking to my mother a couple of weeks ago about what I do, and why I don't like Windows.
Basically, my mum isn't interested in computers. As far as she's concerned, a computer is just a tool to get a job done. That's not to say she's ignorant about computers or afraid of them, but her personal interest stretches as far as running an accounting package where she works.
(Oh, and playing the odd game of Scrabble on a old ZX Spectrum from when I was still living at home, but that's beside the point
But anyway, she doesn't know what Unix is, she's only ever used DOS and Windows. And she doesn't like Windows. It's slower, it's less stable, and there's too much graphical fluff which just distracts her from the job in hand. DOS was easier and quicker from her point of view.
By those criteria, she'd be happy with a command-line Linux shell and a Unix version of whatever accounting package she uses (a fairly obscure bespoke package, I believe). She'd dislike KDE (too much graphical fluff), and she'd absolutely loathe GNOME (waaay over the top, and slow with it).
In this mad rush to make Linux "mom-friendly", how many people have actually spoken to the very people they're trying to accomodate?