Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
GUI Software Businesses Red Hat Software Linux

Red Hat Developing Early Login with gdm 92

Posted by timothy from the psychological-coup dept.
hey writes "Red Hat has been working on early login because, among other reasons, 'If we start GDM sooner, the system will "feel" faster because the user will see a login screen sooner.' Very cool."
This discussion has been archived. No new comments can be posted.

Red Hat Developing Early Login with gdm More

Red Hat Developing Early Login with gdm

Comments Filter:

  • Good idea. I hope Red Hat patents it.... (Score:3, Funny)

    by Picass0 ( 147474 ) on Wednesday April 27, 2005 @02:01PM (#12362431) Homepage Journal
    ... before it becomes a Microsoft 'feature'.

  • awesome (Score:4, Funny)

    by Anonymous Coward on Wednesday April 27, 2005 @02:01PM (#12362433)
    I tell yah, if there's one thing I love more than making my software, simpler, faster, and more effective, it's making it *appear* to be simpler, faster, and more effective. ;-)

  • Not very cool (Score:5, Insightful)

    by stjobe ( 78285 ) on Wednesday April 27, 2005 @02:02PM (#12362463) Homepage
    'If we start GDM sooner, the system will "feel" faster because the user will see a login screen sooner.'

    Yeah, let's all take a page out of the Windows book and fool our users... bleh.
    Why don't we try to make the system really boot faster instead?

    • Re:Not very cool (Score:5, Insightful)

      by kenthorvath ( 225950 ) on Wednesday April 27, 2005 @02:24PM (#12362876)
      Why don't we try to make the system really boot faster instead?

      Three points:

      First, the people who are doing this don't necessarily have the technical knowledge to make the system boot faster. Everyone has their specialties and interests. This is what would make them happy and they in turn are interested in sharing it with you. Don't like it? Don't use it. Why are you posting on slashdot when you could be making the system boot faster? See how that works? It doesn't sound like such a good argument now, does it?

      Second, users take time to enter in information like logins and passwords. While they are doing this, the system can be processing other stuff and making the system come up. When the user and the system are working in parallel, things actually do get done faster.

      Lastly, there is the fairness principle. It doesn't really matter which half of the candy bar is 'bigger' when sharing it so long as one person breaks and the other chooses. Each person feels that they haven't been ripped off without regard to actual physical realities. To this end, if the system feels faster, then why should I complain? It is the user experience that is being made to improve. What else really matters?

      • 1) If this were some random people, fine. To the degree that it becomes default Red Hat behavior, it's something that I'm forced to deal with, or at least to actively disable. (And I work on a multi-user Red Hat system to which I don't have admin rights.)

        2) Try Windows XP and tell me how much faster things get done when your system is completely unresponsive.

        3) See #2.

        • re: 2)

          I work for and with a Linux distribution day-in and day-out.

          I also run a Windows XP SP2 partition on the same type of box.

          The boxes are dual Opteron, less than 6 months old and with a modern 3D video card.

          I run into at least as many problems with Linux (let me rephrase ... with 4 different modern flavors of Linux) as I do with Windows XP.

          Window 95 through Me? Crap.

          Windows NT4? Yes, had a LOT of bugginess but was more stable than previous windows.

          Windows 2000? Pretty damned stable until you trie
          • The unresponsiveness to which I referred is in the period immediately after login, when XP presents you with a desktop but background loading makes it impossible to work. If anything you wrote bears upon that issue, I missed it.

            I guess I could have made that point more explicit, but since it was the topic of a) the post to which I responded, b) the parent to that post and c) the article itself, I hadn't thought it necessary.

            • It was because you made a blanket statement.

              Additionally, on said dual Opteron boxes, both with 2GB of memory, when booting Linux (RH9, Fedora Core 3, SuSE 9.1 and especially Ubuntu HH) I am out of the Windows "sluggish" period after login 30% faster than it takes me to get a full GNOME boot. Just tested it.
          • (I can make Win2K run just FINE on a P3-600 and probably smaller gear ... but I'm not going to get Quake3 running well on it).

            Pssh. Back in college I used to play Quake3 running on a Celeron 300a booted in Redhat 5.2 (Original 3dfx voodoo card, too.) And let me tell you, it ran great.

        • Regarding 2), I've actually written custom scripts to pause a certain amount of time, and then launch AdAware (and other boot-time CPU hogs).

          The scripts also set them to low priority, so you can start getting things done as soon as possible (still some "lag" time when logging in, but a lot less than before).

          To "sleep" without a sleep.exe, a neat trick I saw a few months ago is this: ping yourself for N+1 times (where N is the number of seconds you want to sleep). So to sleep 60 seconds, do a "ping -n 6

        • To the degree that it becomes default Red Hat behavior, it's something that I'm forced to deal with, or at least to actively disable.

          That would only be true if you had some reason to ever want to disable this. I surely can't think of anything bad about it.

          2) Try Windows XP and tell me how much faster things get done when your system is completely unresponsive.

          There are few systems less responsive than Red Hat Linux as it's still loading 10 different network servers, some of which block on DHCP and D
      • Moreover, the user would only get one really long waiting session, instead of two (poweron to login, login to ready to use). This makes getting up and doing something else in that time more plausible, hence saving the user time.
        • I don't see this at all. so, my system gets me a graphical login prompt in 10 seconds as opposed to 30. I log in. Now KDE starts. I wait in both instances, except now my KDE startup takes longer because it's doing other crap in the background.

          I turn on the computer. I go to the bathroom. I get up and go get a drink, and when I come back it's ready to use. You can't remove both delays, and you're just hiding one in the other. It's pointless.

          An anyway, doesn't ubuntu already do this, somewhat? I've
          • I turn on the computer. I go to the bathroom. I get up and go get a drink, and when I come back it's ready to use. You can't remove both delays, and you're just hiding one in the other. It's pointless.

            Kid, you don't know what waiting is until you've flicked the 3-inch long toggle switch of your 80286-16MHz Workstation to "ON", gone to the bathroom, gotten your coffee, talked to a few people in the break room, returned to your desk, and waited another few minutes for your application to finish loading befo
          • I wait in both instances, except now my KDE startup takes longer because it's doing other crap in the background.

            That will rarely be true.

            The extra time is probably unmeasurable, since it's primarily from IO-bound processes, which would have no contention with what you're doing.

            When booting Red Hat Linux, it's not abnormal for individual network service processes to halt for more than TWO MINUTES if the network is down and they can't find their domain servers. This improvement will allow the user to l
            • see, I mistyped that. I meant to say
              "I turn on the computer. I go to the bathroom. I come back, login, I get up and go get a drink, then when I come back it's ready to use."

              PEBKAC made it so half of that was lost. I blame the K.
      • Corollary to your first point ...

        Other people can work on make a Linux distro boot faster (and this is a distro issue more than a kernel issue, meaning all distros will need to agree to make use of the new speedups ... which won't happen ... which means some distros will still "feel" older) whether it is by loading multiple services simultaneously, loading some services on demand or after the boot process, etc. It won't invalidate the work RH is doing now on GDM. In fact, such work is complimentary.

        In oth

    • Re:Not very cool (Score:2, Insightful)

      by BovineSpirit ( 247170 )
      I imagine that their market research has shown that users don't like to wait, and that they're not bothered by the way Windows tricks them. It would be good for my 500MHz K6 because I tend to switch it on, wait an age for the login screen, then wait again for X windows to start up. If they could move some of the initial startup(httpd, mysql etc) to after Gnome is running then that would only give me one wait.
      Of course you are welcome to make whatever improvements you like, and we would all appreciate it i
    • Point 1:
      - If we start GDM sooner, we don't have to start rhgb. starting 2 X
      servers at boot up doesn't play nice with some hardware and rhgb doesn't
      really offer much anyway.

      rhgb is *very slow* (IIRC, it loads up X and then rhgb on top, which is a little wasteful when it gets killed before gdm runs). Swapping this for gdm will probably shave off in the region of 5 seconds of boot time.

      Point 2:
      - If we start GDM sooner, the user can type in his or her username and
      password sooner (as long as we don't actual
    • It depends what you mean by "boot". Ubuntu has had a very similar thing for a long time, and I find the computer perfectly responsive, if a little slower than usual while things finish loading in the background.

      I've actually gone even more extreme on my computer, by starting apache, sendmail, my ftp and ssh servers 10, 15, 20 and 25 seconds after I've finished logging in. By that time all of the various background services have started, and loading them at that point is not noticable at all.

      Of course, my
      • LinuxBIOS has a reputed 5 second boot time.
      • Faster SysV init systems exist.
      • Many of the scripts use horribly redundant syntax, so could easily be optimized.
      • X is big. Really big. If you thought space was big, that is peanuts to X. It would be better if an image of X in memory was dumped and then reloaded, as the start-up time for X is horrible.

    • thats crap, dont even use gdm. oldschool command prompt is the fastest.
    • "Why don't we try to make the system really boot faster instead?"

      They are. Both the init processes and the device configuration routines are being replaced and profiled...and Red Hat is helping (leading?) these efforts.

  • Is this progress? (Score:3, Insightful)

    by rthall ( 240128 ) on Wednesday April 27, 2005 @02:03PM (#12362474) Homepage
    Does it matter that the system will feel slow as a dog as services are lauching concurrent with your login? On the popular non-open-source server platfom, I quite frequently let it sit at the login prompt for five minutes. Then the login feels fast.
    • The point is that there's plenty of free cycles in-between the moments of pressing the key combinations of your name and password. Let's hear it for multitasking!
    • so you waste 5 minutes for the system to feel fast?

      uhhhhh??????????
      • Feel "responsive", maybe. When you're using a system what matters is quick feedback to your actions. So if it's still busy starting up services, and can't context-switch the GUI tasks in fast enough, it will feel unresponsive--and people will perceive that as slow. Since that same mass-market OS doesn't need to be rebooted very often, especially compared to its predecessors, waiting a minute or two before logging in gives you a more responsive system.

        This is why the network guys are always talking abou

        • yes i understand that - but to waste 5 minutes at that point, just looking at a blank screen just to get the satisfaction of a responsible system is just stupid - it's wasting 5 minutes which you could be using to start up the web browser etc...
          • That five minutes is already being used!

            Namely, to start other services, which will be required to use the system. If the system is trying to start Firefox and sshd and samba and crond, at the same time as it's loading all 500MB of X into memory, you're going to experience a bit of churning, to put it mildly.

            It's not like SysV runs at nice -19 or anything.
    • WoW! Redhad diddles with their startup scripts. STOP THE PRESSES!!!!!!
    • I agree. I turn my system on and head for the kitchen to get a glass of tea.
      When I return and login I expect a working desktop within three seconds. IceWM with iDesk icons will do this. The "Other Two" take so F'ing long to load that the programmers decided to create a bootsplash with progress bars to make the wait feel less painful.
      I feel into that trap for a little while. I even created a KDE bootsplash and uploaded it to kde-look.org. It all seems kinda silly now. :)

  • Boot times... (Score:2, Insightful)

    by avalys ( 221114 )
    Maybe if RedHat didn't start so much extraneous crap at startup, they wouldn't need to screw around with this. How about actually working on improving the boot time, and not relying on Microsoft-like tricks to fool the user?
    • PLEASE! Redhat boot time is light years ahead of everyone else. Ever seen heavy duty hardware running Solaris, Aix, Hpux? It's almost common to see them take 1 hour to boot.

      • The question is have you ever seen any Unix machines booting? I have an Ultra 5 Sparcstation running Solaris 9 and I get to xdm in about 3 minutes. That's on a 400MHz machine.

      • Re:Boot times... (Score:1, Informative)

        by Anonymous Coward
        My Debian system take 55 seconds from power-on to KDM.
      • Yeah...my home PC doesn't have a service processor that runs diagnostics on every piece of hardware connected to it. My guess would be that you only need to compare times for OS startup to login screen. On the RS/6000 S80 box I was in charge of, it was never more than a couple of minutes.

    • Re:Boot times... (Score:4, Insightful)

      by NonSequor ( 230139 ) on Wednesday April 27, 2005 @04:47PM (#12365037) Journal
      You're being ridiculous. If something makes the user's experience less frustrating with no cost then how is it a bad thing? I recall an article some time ago where someone put together a proof of concept init system using make that showed that starting services concurrently can speed up boot time. The fact is, this is unlikely to increase the time that it takes to load all of the services and they may be able to reduce it.

      I really can't see anything wrong with this.
  • One of the complaints I hear from Windows people is how long it takes to actually start working once the login has taken place. I know my WinblowsXP partition on my company laptop takes friggin' forever to get going because of all the crap that Winblows starts at boot time. Red Hat has gotten worse and worse as they release newer distros. Hello...Red Hat...are you in there? Screw it...I'm going back to my Debian box.
    • Well from reading the comments on the redhat bugzilla that evidently led up to this, they do have a point that now you wait for a while before you login, and then you have to wait even longer once your logged in. This way at least you can turn on, login, then go get a cup of coffee. So even though total login time is not shortened, at least there is one long "commercial break" instead of two medium breaks

    • Why? Kudzu. (Score:3, Informative)

      by benjamindees ( 441808 )
      Kudzu, which does hardware detection, is one of the worst offenders. Removing it shaves almost ten seconds off of boot time for me, on a 1Ghz box.

      Kudzu is also, however, integral to RedHat's "Stateless Linux" system, which reduces maintenance and increases security by booting from centralized disk images. This process is aided by Kudzu's "on-the-fly" hardware detection.

      So it's a tradeoff that RedHat seems willing to make: ease of hardware support for slightly longer boot times. I'm willing to bet many
  • Making GDM load sooner will definitely make the system seem to "boot" faster. However, if once GDM is up, and it takes 15 seconds before you can begin to login while the other services start, then what at once "seemed" faster, is now slow.
    • I have two things to say about this.

      1. ~/.login
      2. c:\Users and Computers\myname\Start Menu\Startup

      Um...yeah. So let me get this straight. Before we're done loading all of the system daemons, we're going to start processing the individual user's startup items.

      Right...that will speed things right up.

  • graphics? (Score:3, Interesting)

    by monkeyserver.com ( 311067 ) on Wednesday April 27, 2005 @02:23PM (#12362872) Homepage Journal
    Wait... are you talking about graphical login? Just boot don't load X on default, that will *seem* a lot faster.

    I do it out of habit. But if you want to make it into a "go faster" feature, then pretend away!

  • Just so long as... (Score:1, Redundant)

    by wowbagger ( 69688 )
    Just so long as they hold to this one principle:


    If you show me a login prompt, you'd damn well better be ready for me to log in.


    I don't like the statement "We can allow the user to input their name and password, so long as we don't process it until the system is stable."

    BZZZT! WRONG ANSWER!

    I don't mind bringing up X, and showing the boot process info, but do NOT give me a prompt for my username until you are ready for me to log in.

    Personally, I think the whole way init works needs to be revist
    • Personally, I think the whole way init works needs to be revisted - it would be better if you could start all the init processes at once, with each having its standard input, output, and error going into init. If startup script FOO requires service BAR to be active before it proceeds, then BAR ought to provide a means for FOO to check if BAR is ready (and block if not).
      Good idea, but the only thing you'd get is close to 100% CPU usage upon startup and a startup that is at most that much faster (i.e. by the
  • There are a number of things that can be done to speed up the booting of a Linux system. The most significant of which is to start many of the services concurrently as opposed to the current practice many distros have of launching them one at a time, then wait to see if it fails or works before launching the next one.

    By launching them concurrently (subject to dependency constraints) the startup time can be shortened to a small fraction of the current time needed.

    There are articles on how to do this and

    • Sun has already taken this track on Solaris 10 with their Service Management Facility. See SUN's quick summary of SMF [sun.com]

      I am still getting used to SMF, and luckily they also keep backwards compatability with the rc.d init scripts.

      Provided SMF isn't under 100 patents, maybe LINUX can pickup a few of Sun's good ideas once OpenSolaris comes out later this year.
    • I may be talking out of my behind depending on how Linux does disk scheduling, but when it comes to multiplexing I/O from magnetic disk, multiplexing (mostly) sequentual reads can slow down the overall process, as 'context swaps' (to use a metaphor) cost you a few ms, which can be really damaging if multiple processes want to talk to the disk.

      Of course, there are so many parameters that go into this dependent on what daemon is being started, so it may be a good idea for the boot process to attempt to be a
    • Gentoo's init system uses dependencies already. They already have a flag for parellization. It doesn't seem to actually parellize anything, but it would seem that they are working on it.

      Me, I improve my boot time by using suspend2 instead of shutting down. If I limit the amount of stuff copied to disk, I can avoid thrashing on boot but still have a wicked quick startup, especially with the lzo compression.

  • Three words: (Score:5, Insightful)

    by roystgnr ( 4015 ) <roy AT stogners DOT org> on Wednesday April 27, 2005 @02:35PM (#12363055) Homepage
    make, make, make

    Starting up a Linux system requires satisfying some dependencies. You don't want to try mounting nfs disks until after bringing up the network. You don't want to start the X server until after the X font server is running.

    But why, exactly, must gpm not start until sendmail is finished? Just because some Red Hat employee decided that sendmail should be numbered 80 and gpm numbered 85? It's not his fault, anyway, since starting them the other way around would be just as bad.

    The underlying speed problem isn't what order Linux services are started in, it's the fact that they're only allowed to start one at a time. There's a reason why you're recommended to compile with "make -j 2" even on uniprocessor machines: even when an individual program is running as fast as it can, odds are it's I/O bound often enough that the CPU can profitably do something else at the same time. Even multiple programs waiting for the hard drive can start faster if they're started simultaneously: the drive controller can pick up whichever data is closest to the read head first, instead of being forced to data in some arbitrarily chosen order.

    I know I'm not the first person to realize this; although I can't find a web page at the moment I recall reading about someone doing this long ago. What I don't recall reading is any reason not to make your distribution start up this way. Backwards compatibility could be easily satisfied by adding phony dependencies for S01 through S99 (which in turn would depend on all the services which were listed earlier). Bloat is a concern, but even GNU make is a fraction of the size of the initscripts package on my system. If you start background and interactive services concurrently you have to worry about responsiveness, but that's what the "nice" command is for.
    • Check out the Gentoo init script dependencies. And they are working on parellizing. I'm not sure if it's done yet, though.

      For instance, to add sshd to the default runlevel, I just do:

      rc-update add sshd default

      The scripts will most likely place it towards the end, but they make sure it goes after networking, because sshd obviously depends on networking. Should the network fail to come up, sshd won't be attempted.

      Also, if I want to start sshd manually: /etc/init.d/sshd start

      will automatically start ne

  • Hmmm... (Score:1, Interesting)

    by advocate_one ( 662832 )
    when was the last time I booted this system???

    some 20 days ago...

    20:33:27 up 20 days, 23:41, 2 users, load average: 0.31, 0.35, 0.29

    when was the last time I botted my other system???

    20:34:40 up 293 days, 7:25, 7 users, load average: 0.25, 0.17, 0.10

    why the F would I ever need an early logon to GDM???

    • Re:Hmmm... (Score:1)

      by Anonymous Coward
      why the F would I ever need an early logon to GDM???
      It is quite evident from your uptime that you do not shutdown or reboot your computer very often. Therefore, you probably are not in the target audience of this feature.

      I'm not sure why you couldn't figure that out by yourself.
      • yes well... I can sympathise with those who boot once per day... the vast majority of the time, they, like me, will be fixing their morning coffee while the machine boots, so they, like me, will come back to a system that is ready for login... (yes, I suffer having to use NT at work and having to shut it down at cease work to comply with our fire regulations... only certain servers get left on overnight, and those have large dayglow signs over the power switches...)

        As far as I'm concerned, anyone who has to

        • > anyone who has to boot more than once per day is either a masochist

          Or someone who can't stand the noise of the damn computer when not using it. Hell, I even made a watercooling setup for the CPUs, that's how much it bothers me. I still have that power supply fan though, and when it's on, I HEAR IT. Silence is golden.

    • Re:Hmmm... (Score:3, Insightful)

      by peterpi ( 585134 )
      You wouldn't.

      I would. I last booted 25 minutes ago. Power usage and fire risk are concerns for me.

  • improve overall startup performance using 'make' (Score:4, Informative)

    by dan_bethe ( 134253 ) <slashdot@@@smuckola...org> on Wednesday April 27, 2005 @02:37PM (#12363099)
    An IBM researcher [ibm.com] has a sample implementation of a dependency system for standard SysV init scripts. It uses 'make' to provides deps instead of the crude, standard ordering system. Search the article for the word "dependencies" and start reading there toward the bottom if you already know how SysV init works.
  • In my house (maybe a little atypical) we have DSL and machines scattered around the house. They're usually hot, with a browser seconds away. The last time I booted the Gentoo box was two weeks ago (kernel upgrade) and the OBSD boxes haven't been booted since the hurricanes last year.

    The wife's and daughters' MS-Windows boxes go through regular b0rk-and-reboot cycles, so boot time means something to them - but not to me.

    I wonder how many people with DSL households shut down their machines between uses?

      • "Laptops" -- good point, no sense burning your battery up while you're in transit.

        (If you carry one around! One of our OBSD boxes is a beater Compaq Armada, which serves as the household firewall. It never gets turned off, or moved from it's spot on the bookshelf, or even hardly ever touched.)

        Does hibernation work yet? Or is that one of those maddening model-dependent things in Linux?

  • Fooling the user the right way (Score:3, Interesting)

    by Santos L. Helper ( 808000 ) on Wednesday April 27, 2005 @02:54PM (#12363364)
    It's not always a bad thing to fool the user if you can get away with it. Jef Raskin's Canon Cat system did exactly that. On starting up it would show the user a bitmap of what the user was last working on while it loaded up the actual data in the background. Then when it's ready, it would replace the bitmap with the actual display. The thing that Raskin figured out to make it work was that it took users a couple of seconds to reorient themselves and recall what they were doing, so they would just sit and stare at the screen for a bit. And the Cat can *always* load up the real data and be ready for input before the users themselves were "booted up."

    But from TFA, it doesn't sound like the redhat guys are going to do it the right way, which means the users will figure out they've been fooled and you've just gone through all that trouble to piss them off.
  • I don't want to bash RedHat on it, but I already have it: Ubuntu Hoary starts GDM before some stuff (I could see the startup of ACPId after the "starting GDM" message and before the GDM really appeared).

    One point to them is that they were the first trying such things, IIRC.

    • I don't want to bash RedHat on it, but I already have it: Ubuntu Hoary starts GDM before some stuff (I could see the startup of ACPId after the "starting GDM" message and before the GDM really appeared).

      SuSE does this already as well... at least in 9.2, I think in 9.1 as well but I can't tell for sure. Heck, even Windows does this for years now !

      There's still a lot of room for improvement. I once saw a nice demo implementation of a boot process controlled by make. The idea was that you specify the boot

  • die init die (Score:3, Informative)

    by Hard_Code ( 49548 ) on Wednesday April 27, 2005 @03:18PM (#12363749)
    Sys V init scripts are just archaic and are showing their age and preventing more sophisticated forms of startup. Why doesn't RedHat investigate replacing Sys V init with a new, dependency-based, parallelizable startup system like Mac OS initialization system or Seth Nickell's proposed "SystemServices" init system:

    http://www.osnews.com/story.php?news_id=4711 [osnews.com]
    http://www.gnome.org/~seth/blog/2003/Sep [gnome.org]

    This could easily be backwards compatible such that there are services defined which are simply one-to-one mappings to scripts. Once it's dependency based, you don't have to worry about assigning hardcoded priorities manually and then writing dock gadgets that tell the user when the services are done "starting". As a user I couldn't care less that the services are done starting. Programmers have a futuristic technology called semaphores that can be used to block until a required dependency is fulfilled. If you want to print, and the print spooler hasn't started, instead of blowing chunks, you just implicitly start it. Magic! Ideally, ALL services would be lazy by default unless specifically told by the user to start up automatically (i.e. ssh server, web server, etc.)

  • LinuxBIOS (Score:2)

    by jd ( 1658 )
    A five second boot-up time will make things a LOT faster for real, not just "apparently".

  • It do speed up boot (Score:2, Informative)

    by paulatz ( 744216 )
    If you read the thread on redhat, you will find out that the early-start gdm can shorten the boot process by a dozen seconds. It is not just feel.

  • This is one of the features I detest in Windows XP. The login screen appears early but the desktop crawls and splutters while loading, due to all the background activity as services start. The taskbar noticeably renders itself; green bar first, then the outline of some buttons, then the systray slowly loads a few icons. Argh. Click on the Start button and the gigantic Start Menu appears, but it randomly DISAPPEARS before I get the chance to pick a program. Even worse is when you're 3 levels deep in the Prog

  • Solaris 10 already solved problems like this with SMF:

    http://www.sun.com/bigadmin/content/selfheal/sde v_ intro.html

    I can login to my JDS 3 Desktop and have everything up *much* faster than I ever can with RedHat Enterprise Linux 3.0 WS (which I also have installed).

    Nice to see RedHat catching up finally :)

    • Re:Solaris 10... (Score:1, Interesting)

      by Anonymous Coward

      The NIH syndrome runs so thick, here, that they'll try to reinvent SMF with makefiles and bash scripts. Bleh.
  • Not really a big surprise that this is happening, it would make sense for Red Hat to do this as it becomes more popular. Just because Windows does this doesn't mean its bad; it is all about your preference. I don't care if Windows happens to do the same.

    Personally, I use GDM to make it easier for my girlfriend to log onto my computer and use X (plus man, its always nice to turn on your computer and see a sweet looking picture of a Portugal Beach warming your screen).

Slashdot Top Deals

Put your Nose to the Grindstone! -- Amalgamated Plastic Surgeons and Toolmakers, Ltd.

Close