Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
GNOME GUI

GNOME 1.4 Beta 2 is Out 91

Posted by michael from the keeping-up-with-the-joneses dept.
Maciej Stachowiak writes: "The GNOME 1.4 Release Team is proud to announce GNOME 1.4 Beta 2 "Hit Me Baby, One More Time". This is only a beta and there may be problems with compiling and running. However, if you are adventurous and would like to help with testing, get it from your favorite GNOME mirror site in /pub/gnome/stable/betas/gnome-1.4beta2. We would also like to announce the GNOME Fifth Toe 1.4 Beta 2 release, a collection of additional packages that are not part of the core desktop but designed to work well with GNOME. This should also be available on gnome mirrors in /pub/gnome/stable/betas/gnome-fifth-toe-1.4beta2. Bug reports for most packages should go in one of the following, depending on the module: GNOME Bugzilla, Eazel Bugzilla or Ximian Bugzilla."
This discussion has been archived. No new comments can be posted.

GNOME 1.4 Beta 2 is Out More

GNOME 1.4 Beta 2 is Out

Comments Filter:
  • Whats the next one going to be..."Shake your bonbon" or "Gee, I'm a gnome so maybe I can toss E's salad..."
  • Yes I realize I could install from source manually, but I would more likely break something than end up with a useable system. It might not just be the 2.4 kernel, but while the installer works fine on redhat 7.0, it fails (after downloading 100+MB) with a core dump on fisher.
  • Nah, it will be called 'Shake you bonobo'
  • Truth is, you don't know what stange dependencies the installer might have on the kernel. They could have relied on kernel code that they shouldn't have. I have a hard time understanding why a gnome installer would need to rely on kernel internals to begin with. But don't be quick to point the finger at the kernel developers. Also, if you "carefully" update the kernel like you said, it would be slowed down in its backwards compatability.
    Bob
  • Didn't mean to imply it was the fault of the 2.4.x kernel. When I said "kernel 2.4.x breaks the installer" I kinda ment "too bad the installer breaks so easily".
  • Exactly what I was about to respond with.. This seems like a MS Marketing ploy to me.

    And what the hell is slashdot doing posting a Beta release as news?!
  • does anyone know - ballpark figure, how many megabytes of crap i would have to download to upgrade my current GNOME (gnome-config tells me i have gnome-libs 1.0.54, shipped with Mandrake 7.0) to this new one?

  • nautilus up for the job (Score:3)

    by Anonymous Coward on Wednesday February 28, 2001 @07:26PM (#393928)
    I must first say that while I'm impressed with the look, feel, and features of Nautilus, it's very slow. Should such slow or bloated software really be a part of gnome? I almost feel like I'm being forced to use old gnome versions along with Window Maker to keep reasonable speeds. However, please don't take my statement as negative but more as constructive criticism. Can we expect to see speed improvements in GTK and Nautlius down the road?

  • Re:how big is GNOME 1.4? (Score:2)

    by Anonymous Coward
    du -s in my directory with all the rpm's from the first beta says its 94 megs... but that includes all the devel packages too without the devel packages, its 50 megs
  • Damn, this PII is getting slow. Is GNOME getting slower by the day, or does Intel build timers into its chips that halves the clock-rate very year?
  • that you do an updatedb, because it won't work without it first. some programs also refuse to work with 1.4 due to a bug in the versioning.
  • From what i hear, and after looking at the buglist on eazels bugzilla server, its pretty obvious that Nautilus has no place on my desktop.

    Maybe they'll improve the speed at which it runs, but, IMHO, it will just make the GNOME guys look like dicks when they come out shipping this bloated piece of sh*t in a final product.

    'Yeah, this desktop is better than KDE because.. uhh, because.. well, our windows don't open as fast, it might be confusing to the new user'

  • how to get this working if the installer dumps (Score:5)

    by margulies ( 192201 ) on Wednesday February 28, 2001 @07:40PM (#393933)
    if the installer cores on you, try the following:

    cd to /var/cache/red-carpet/packages
    then issue "rpm -Uvh *"

    works for me on RH7.0 (even on fisher).

    i believe the installer dumps right before or during the final call to rpm. not sure why it works from the command line and not from within red-carpet.
  • Some of these mirrors are mighty broken:
    230- ftp.cybertrails.com
    230-Due to limited disk space at the moment,
    230-we have had to discontinue our gnome.org
    230-mirror for a month or so.

    can't find epoch.res.cmu.edu: Non-existent host/domain

    gnomeftp.blue-labs.org doesn't have beta up yet...

    Well, i think you get the picture, lots of broken mirrors.

  • whats new?

    itd be nice if when 'new software releaces' are posted on slashdot if we could get a changelog / whats now url.. so we can look at it and go "oooo i cant wait to have that!"
  • Article today "Mandrake 8.0 beta is out", it's just a slow day. They announce the beta KDEs as well.
  • it breaks on fisher because the api to rpm changed between 4.0 on 7.0, and 4.0.2 that comes with fisher

  • Re:nautilus up for the job (Score:2)

    by Anonymous Coward
    while Nautilus is very cool, it's almost like they forgot about the issue of speed. It doesn't seem as if they are staying within the normal computers means. However, despite the users cpu speed, nautilus is way too slow. I certainly don't see gmc, anything from kde, or explorer in windows act and respond so slowly. Part of the fault is Nautlius being too bloated, perhaps some design, and maybe even GTK. In general, GTK is slow as shit while QT seems to be very fast. It's almost a shame that GTK became more widespread over QT simply from license issues. GTK certainly needs to get it's ass in gear or it needs to be dropped for QT.
  • ftp.snoopy.net:
    ftp> cd pub/gnome/stable/betas/gnome-1.4beta2
    550 pub/gnome/stable/betas/gnome-1.4beta2: No such file or directory

    ftp> open slave.opensource.captech.com
    ftp: slave.opensource.captech.com: Host name lookup failure

    download.sourceforge.net (ftp) doesn't have beta2 yet either, just the first. And rpmfind has too many users already. :)

    So, good luck finding a mirror :)

  • I've always thought the install failure has something to do with using newer versions of RPM v4.x, such as that shipped with fisher or that included in the install of Nautilus PR3 for RH7. These later versions break up2date and helix-update as well.

  • Hmmm... beta release of Redhat (fisher) and a beta release of gnome, wonder why it doesn't work? I'm running redhat 7 with 2.4.2 kernel and the beta gnome with no problems, maybe because redhat changed a lot of things in the fisher beta(including to a beta glibc if i'm not mistaken)?

    in any case, don't expect to pile one beta on top of another and see it work. most betas have enough problems weeding out bugs with established systems let alone with other beta versions (anyone else see a perpetually recursive loop here?)
  • Are you sure about that? The installer gives a big warning about not being supported on anything except 2.2.x kernels, but sounds like it *might* work. After downloading I found out it actually didn't work.
  • Talk to Eazel about it, I just copied the text from my terminal. In fact, I dare you to file a bug report on it: http://bugzilla.eazel.com [eazel.com]

  • please don't flame me over this... (Score:4)

    by Ensign Nemo ( 19284 ) on Wednesday February 28, 2001 @08:12PM (#393944)
    I always thought KDE looked neater and more 'professional' than GNOME. But with the recent screenshots of both it appears to me that GNOME has taken the edge.
    GOD I lOVE competitive cooperation! This just means on the next release KDE will look better. then GNOME, then KDE. ;>
    How do they run comparatively? I ask out of ignorance since I haven't used either in almost 8 months now. I hear a lot of people moaning about Nautilus. Can anyone give me unbiased (if there is such a thing.) information backed up with numbers and examples?
    In any event. To everyone involved in both KDE and GNOME: Keep up the good work!! your hard work is paying off.

  • Re:Time to upgrade. (Score:3)

    by zerocool^ ( 112121 ) on Wednesday February 28, 2001 @08:19PM (#393945) Homepage Journal

    I noticed the Intel Chip Clock-speed Decrease a long time ago.
    Recently i emailed an intel rep about it...

    TO:support@intel.com

    FROM:**email address omitted**
    REPLYTO:**email address omitted**
    DATE:JAN12 2001
    SUBJECT:Slowing processors

    Dear Sir or Madam.
    I have had problems with my intel chip - every year it seems to become slower, even though i have not done anything to the chip its self. Are you familiar with any problems in relation to this phenomonon? I am quite baffeled. Please write me back at **email address omitted**.
    Thank you in advance, ~Will.

    //end of letter

    TO:**email address omitted**
    FROM:support@intel.com
    REPLYTO:support@intel.com
    DATE:JAN13 2001
    SUBJECT:RE:Slowing processors.

    DEAR WILL:
    HOW ARE YOU GENTLEMEN?
    ALL YOUR BASE ARE BELONG TO US.

    INTEL SUPPORT.

    //end of letter

    ~zero


    insert clever line here
  • That's not a beta, that's pre-alpha.

    Unless we're talking about difficulty compiling on different platforms, there's no way that this is up to beta quality if there are difficulties compiling the desktop.

    IMO, if a build process is difficult or buggy, especially if it is an open source product that most people are expected to compile, then it reflects very badly on the quality of the code. Difficult build usually means crappy code. I can't remember ever being proven wrong on this point in my experience.

    If there are difficulties in compiling, then this shouldn't even go out the door. It should be a snapshot and that's it. I have difficulty enough with the kernel people not being disturbed when a development kernel fails to compile, I guess it's difficult to check the dependencies of every single kernel module and driver. But IMO, there is NO EXCUSE for difficulty compiling a desktop. It just points to extremely lax engineering at the core of the project.
  • Gtk and Qt are just about indestinguishable on my system. I run Konqueror a lot on my Gnome system and apps like Evolution and Konq perform about the same. My system isnt exactly supercharged either. I think that there is definitely room for improvement in terms of speed in both environments, but come on, it really isnt that bad.
  • Of course it wasn't mentioned here, because the evil slashdot.org clone site www.slashdot.com [slashdot.com] mentioned it.

  • IMO, if a build process is difficult or buggy, especially if it is an open source product that most people are expected to compile, then it reflects very badly on the quality of the code.

    GNOME is designed for POSIX conforming systems with an X11 server. However, some systems that claim to conform don't in practice (such as AIX [everything2.com] and Pains [everything2.com]).

    But IMO, there is NO EXCUSE for difficulty compiling a desktop.

    Unless you're trying to compile it on a "weird" platform or a platform whose unit price is out of the typical consumer PC price range (that is, anything that's not built around a single PowerPC or x86).


    All your hallucinogen [pineight.com] are belong to us.
  • if you want a good fast window manager under gnome, try gnome 1.2 and sawfish. i'm currently running 0.36, and it's proven itself to be quite a worthy replacement for windowmaker (which i used to run, up until about 8 months ago). i personally don't use nautilus, although i'm not resigned to never giving it a chance... as for gtk, it's pretty fast for me... i have no problems whatsoever.

    --
    you must amputate to email me

  • Re:nautilus up for the job (Score:1)

    by Anonymous Coward
    I was a strict Window Maker only user for such a long time and I then I decided to use gnome session with sawfish. I liked the combination very much but I recently switched back to using Window Maker for my windowing and running the gnome panel along with it. In doing this, I've seen a huge difference. Window Maker handles windows much faster than sawfish. I do mean a lot faster. Windows seem to open much quicker, right click for window options is 800% faster, and it seems more stable. Obviously, I'm back to where I started and that's Window Maker. God Bless Window Maker for doing something right.
  • Let's see --- how, exactly, does the conclusion "GTK is slower than QT" come from a comparing the speed of a huge, bloated GTK app to light, fast QT apps?

    In my experience, both GTK+ *and* QT have been damn fast on my system. I can't tell the difference in speed (but I like GTK for other reasons).

    Can you give me an example of a specific widget or idiom that's slower in GTK than QT? Didn't think so.

  • Re:please don't flame me over this... (Score:3)

    by q000921 ( 235076 ) on Wednesday February 28, 2001 @09:40PM (#393953)
    Too bad that all the desktops are competing over which one looks visually most appealing/modern/styled.

    What about competing on which one is easiest to program for? Which one has the smallest learning curve for programmers? Which one has the lowest footprint and still provides full functionality? Which one is the easiest to use?

  • That's debatable. NT's service packs have never broken anything for me, but upgrading glibc (2.2.2-pre -> 2.2.2-final) once broke 'ls' of all things!
  • 50MB? What's in there! Seriously, one has to admit 50MB is getting pretty hefty for a system. The entire BeOS core directory is about 30MB of binaries (including drivers and the whole bit). This isn't a plug for BeOS, just a point of reference. What is GNOME stuffing in there?

  • changed to KDE after years with GNOME (Score:3)

    by HomerJ ( 11142 ) on Wednesday February 28, 2001 @10:01PM (#393956)
    Nice to see the gnome team respond with a quick 2nd beta. What I'm about to say isn't flamebait, just my opinion.

    That first beta trashed my system. Installed nautilus, which kinda took over everything that gmc did, but with about 1/2 the useable functionality. And not to mention that the mozilla intergration didn't work(yeah, I had all the correct packages). And it was just a slow expierience over all. Saw the promise in what 1.4 and 2.0 could be. But as of now, it's not nearly there.

    Decided to see what all the fuss over KDE 2.1 was about. A simple "apt-get install task-kde" had it installed in a few moments. What a differnece in night and day this was when I first started it up.

    First off, I noticed the AA Fonts. And then just the overall speedup compared to even the stable 1.2 gnome. I did think what most people think of kde though, it just being an improved Windows interface. A simple change in a theme made it nothing that looked like it's former self.

    Then I checked out Konqurer. I didn't expect much. However, after using it for a couple days, I don't see how ANYONE can not use this. In useablitly, speed, and stability, it's between IE4 and IE5. Not to mention features such as killing popup windows, that IE will never have. And not to mention speed. I clicked the desktop icon, and it displayed the start page. Pages loaded and rendered faster then any mozilla optimized build that I've compiled myself.

    But what I don't think most people understand that you don't have to totally pick one over the other. I do like evolution, and I still use it for my e-mail. I still use gaim, and a bunch of other "gnome" programs. If I would have got around to actually trying konqurer, I would have ran it in gnome. Using kde or gnome, doesn't tie you to their aps.

    So while you all are trying out this new Gnome 1.4 beta, type an apt-get install task-kde and give the new kde a whirl. I ran gnome since pre 1.0 days, and it made a convert out of me. And if you don't like it, there is always apt-get remove task-kde

  • X marks the spot (Score:4)

    by Ukab the Great ( 87152 ) on Wednesday February 28, 2001 @10:14PM (#393957)

    Do many of the things that Eazel does (zooming, playing MP3's in file manager, etc) slow Nautilus down? Certainly. But OS X/Aqua does many of the same things Nautilus does and does it also using unix kernel (albeit BSD) and does it with far more transparent graphics and the whole time doing all of this in a vector based PDF graphics systems. Quartz/Aqua has to have way, way more overhead than Nautilus and X running with the most gaudiest, bloated Gtk theme.

    And yet OSX is still doing it faster.

    I know comparing two different kernels on two different graphics systems on (typically) two different architectures is like mixing apples and oranges (pun intended). But such a great disparity between the two environments that favors the one that has to do more work strikes me as odd. I may be wrong, but I'm almost positive that this is a problem with X. We really, really need something better than X and we need it now.

  • especially if it is an open source product that most people are expected to compile

    I'm afraid given the size of gnome ( as well as of other similar products ), less and less people are willing to compile it from scratch.
    And as for all open-source products, the less users try a feature, the more the feature is buggy. Configure scripts can perform their magic flawlessy only because other people ironed out the many bugs in them.

    Also the current stable gnome 1.2 reselase has small compiling issues in some package, if you get the tarballs from gnome site.

  • I just want to point out that your mother doesn't care about the "easyness to program". She cares about the e-mail and some web shopping.

    Programmers are not the majority of computer users...

  • Re:X marks the spot (Score:2)

    by Anonymous Coward
    well, a lot of it is really just GTK in my opinion. GTK's text widgets are god awful for instance. However, X does play a big part of it along with the drivers for X. The X team keeps X way to generic for modern cards. X really needs more extensions for hardware support. Xrenderer was a good start but now X needs a real accelerated alpha layer in order to do transparencies worth a shit. X also needs more support for other accelerated features and xv needs more support for features too. It's good that XV supports yuv-rgb, hardware scaling, etc... but what about extensions for motion compensation, etc.....? Perhaps X needs more commercial support to get such things done.

  • Re:"May be problems with COMPILING"?! (Score:3)

    by jirka ( 1164 ) on Wednesday February 28, 2001 @10:39PM (#393961) Homepage
    I'm glad you volunteered to help with this and send it bug reports and patches. You see, GNOME is a cooperative effort of volunteers, so you have to volunteer to fix stuff. We aren't excusing ourselves from build troubles.

    So ... yes, we are taking patches. That is, if you are willing to get off your whining ass and do something instead of putting down people's work that you just got for free.

  • Hahahaha :) Don't flame you over that?

    No offense or anything, but that's just drivel.

    KDE makes great pains to be easy to program for.

    GNOME has a small learning curve for a number of programmers, as it's C-based.

    GNOME has the lowest footprint and provides the most functionality.

    KDE is easiest to learn(but not to use; the longer something takes to learn, the more complex it is. Generally, the more complex an app is, the easier it is to get work done. Ease of use is directly related to how easy it is to get work done).

    And both projects tout those aspects :)

    So, indeed, I will flame you, karma whore :)

    Consider yourself flamed.

    Barclay family motto:
    Aut agere aut mori.
    (Either action or death.)

  • Re:X marks the spot (Score:4)

    by frantzdb ( 22281 ) on Wednesday February 28, 2001 @10:46PM (#393963) Homepage
    Can you say Hardware Video Acceleration? Currently X is doing all it does (generally) with your CPU. If you have hardware accelerated graphics, then the computer can do more with less work. I have heard of some Enlightenment testing with a full alpha canvas with framerates in the hundereds of frames per second for large, complex 2D graphics. The problem is not X.


    With regard to Nautilus, the answer I keep hearing is that they arn't done with speedups. Only time will tell, but the people working on it are aware of the issues.

    --Ben

  • The main issue here is that GNOME is built on top of Xlib, X windows, etc. They have to write a lot of library code on top of existing library code in order to generate a useful system. Xlib isn't exactly forgiving, either.

    That said, (and as a BeOS plug) Be is faster, more powerful, and smaller. It's also less themeable (I'm running it now, everything can be one color or another, but no pixmaps, and certainly no engines). As far as GNOME itself is concerned, I don't know exactly what the bulk is except that the libraries let you do lots of stuff without a lot of code. BeOS is fairly direct by comparison.

    Daniel

  • Re:nautilus up for the job (Score:3)

    by frantzdb ( 22281 ) on Wednesday February 28, 2001 @10:47PM (#393965) Homepage
    The issue here is that GTK isn't double buffered. GTK 2.0 will be, thus there will be no flickery redraw issues.

    --Ben

  • Re:X marks the spot (Score:5)

    by dbarclay10 ( 70443 ) on Wednesday February 28, 2001 @10:48PM (#393966)
    We really, really need something better than X and we need it now.

    Okay :) You've got a text editor, you've got a compiler, and you've got source code. Start coding.

    No? Why not? Listen, replacing X isn't going to be easy. And unless you're going to do it, shut up and stop whining. Instead, THANK the people who have *given* you a Free implementation of the X Windowing System. Got it? Good.

    Barclay family motto:
    Aut agere aut mori.
    (Either action or death.)

  • Re:Too bad linux kernel 2.4.x breaks the installer (Score:5)

    by itp ( 6424 ) on Wednesday February 28, 2001 @11:02PM (#393967)
    It fails on fisher not because of the kernel, but because of the broken version of RPM that is shipped with fisher (and with Nautilus PR3). There are several other posts about this in this article, or you can read up for more information at rpm-list@redhat.com or red-carpet@ximian.com.

    Basically your package database is corrupted by using by using RPM 4.0.2, and the corruption causes clients like Red Carpet, up2date, etc to crash.

    We're talking to Jeff Johnson, the RPM maintainer, to come up with a solution as quickly as possible.

    --
    Ian Peters

  • Re:X marks the spot (Score:1)

    by Anonymous Coward
    This is on its way. Currently, as far as I know, the i810 driver has 2d acceleration, as do the NVidia drivers (or so they tell us) and the rage 128 stuff is on a branch right this moment. I think the radeon's got it too, but it's not very optimized. We'll get accelerated 2d and we'll see how performance goes.

    Personally, I think it's just fucking Nautilus itself. X doesn't seem to slow down gmc or galeon much, and that's with Gnome running on top of Gtk running on top of Gdk running on top of X running on top of the linux kernel (at least on this system.) Performance doesn't take a hit until you introduce Nautilus.

    The problem is really that Nautilus is trying to do too much at once, and is spinning its wheels trying. I haven't looked at the code, but I'm guessing it's not the most optimized piece of work you've ever seen. Just because it duplicates a lot of Aqua's functionality does not mean it's coded nearly as well as Apple's system. X doesn't have a problem doing a lot of the stuff that aqua does (display postscript libs are readily available for X if you don't believe me), it's really just Nautilus. In short, don't blame X. Blame Nautilus.

  • AFAIK the 2d acceleration is pretty generalized (the XAA in XFree 4.x, I think in later 3.3.x too). So any driver that implements this will have "good 'nuff" 2d accel, which is most of them (again AFAIK; I did use one card that didn't (a shitty embedded SiS chipset video thing), and that sucked[1])). I know that, for example, things besides the rage128 in the ATi line are accelerated (e.g. Xpert 98, my fav' ubercheap agp card). I've also seen Matrox cards perform impressively in this regard (G200 & G400).

    WRT Nautilus, I know basically zero about it but another poster is saying that they haven't addressed optimization yet (good for them, as Knuth said: "Premature optimization is the root of all evil.").

    [1] I'd move a window, and it would screw up the blitting, so the window would leave glitches on the desktop and surfaces "below" it, as well as picking up glitches itself. Oh, and of course since everything was integrated and sharing the same limited bandwidth on the MB, moving the window caused so much traffic or something that the audio from a playing CD would stutter. :-( This was on the POS[tm] brand developer workstations I had at my last startup job (but to be charitable, they were very cheap and did basically let us get the job done).


    --
    News for geeks in Austin: www.geekaustin.org [geekaustin.org]
  • Will GNOME become Britney? Good looking, friendly for young girls, and empty inside?
    PS. it's not flame, I use GNOME :)
  • 1. Don't agree. AIX is as standard as it gets.
    2. Comparing AIX5L with NT is asking to be flamed since the L stands for Linux.
    3. I used to compile earlier versions of KDE on AIX. Never had a problem and when I did, the developers always took it seriously.
    4. Fix it, don't invent excuses.

    Cheers,

    Matt
  • Isn't Gnome still a virgin?
    --
  • Let me put a disclamer before all this by saying that I haven't downloaded the GNOME 1.4 beta 2 code, nor do I plan to, because I'm really not interested in running Gnome. I don't fully understand what is involved in these supposed compilation errors. I just reacted to the statement of either the contributor or the slashdot editors that there might be compilation errors, and they tried to lump them together with runtime errors. That's a VERY bad misconception.

    I'm sorry, but I can't just lump problems with the build system as one of those normal "Well, the source is available, so stop whining and FIX it!" kind of bugs. Why? Because:

    1) Fixing problems with the build system often takes more knowledge about all of the code than fixing bugs in the code. I don't just need to understand the subsystem that has the code I want to modify, I have to understand ALL of the code, how it is all supposed to fit together, what assumptions were made in the compilation, and how it is supposed to interact with the system libraries. And I often have to know this information down to the level of each line of code because it is usually due to some arcane DETAIL why it won't compile. Or the code is MARGINAL C or C++ and today's compilers will not take it anymore. Unless these problems are just really small, "stupid" problems, it's a VERY tall order to ask someone who has never seen the code before to try to fix it. If I'm porting this code to a new platform, then I expect this kind of difficulty, and I'll go through with it in order that other people don't have to go through with this difficulty when they want to use the software (and besides, then I'll get recognized for porting it. :P :-) ). However, when I am using it on a mainstream platform, my patience quickly runs thin, especially if it is supposed to be a BETA.

    2) I really do use the quality of the build system as a metric for the quality of the leadership and the engineering quality of a project. I do this because:

    a) The quality of the build system directly influences the ability of people to contribute to the project. If you can't compile code, you can't really fix bugs in it.

    b) There's really no excuse for it. If code makes a project NOT BUILD, then it shouldn't be in the build until the project can build with it. And if you're allowing code that won't even
    BUILD into the tree, then how can I possibly think that you unit test new code to make sure it doesn't have serious bugs in it? Having constant build problems is a symptom of VERY bad and lax project management, that isn't striving to improve and guard the quality of the code.

    c) It is also a VERY good indication of software quality in general. If a project won't even
    compile on its primary platform, then the code is probably crap, because the same attitudes that produce a screwed up build system produce screwed up code. Good
    quality-oriented developers won't put up with a bad build system, they'll FIX IT, because
    they keep running into the problems. Therefore, it is a dubious effort at best to fix a truely
    screwed up build system as an outside contributor, because once it is fixed, you'll most likely just get a program that is completely riddled with bugs, a project that just needs to be completely rewritten. I've always held the philosophy that if the build process gets completely screwed up for a long period of time, it is the project leader's responsibilty to get it back in some kind of working order to demostrate that there is some reason to keep contributing to the project.

    3) It's one thing to have compilation problems in the snapshots, because that's what they are, an arbritrary snapshot. I could have contributed something that majorly fucked up the tree right before the snapshot was taken, and then I immediately fixed it after the snapshot. But Beta's are different. If NOTHING ELSE, take a day to make sure that the damn thing still compiles. Otherwise, you're wasting everyones time. There's not much that I can do if half of the files compile, and then the build majorly breaks on the other half other then to say "Ooh..look at the cute little object files!".

    To make my position clear, I would easily rate a project that immediately segfaults on startup over a project that won't compile. At least the project that segfaults DOES something.
  • You're right, there is the new Enlightenment Canvas (I think it's called Evas or something) and it's said to be quite fast (haven't tried it, but I do believe it) and it runs on X ... BUT ... it uses OpenGL, (via GLX I suspect) so it's not using the X-Windowing System to draw things! And thats the way it achieves the speed! So X is indeed the Problem!

    Btw, there is the XAA (X Acceleration Architecture) and it is supported by pretty much every X-Server in XFree86. If you want to see how slow it gets when you really do everything in the CPU try using 'Option "NoAccel" "true"' in your Device-section of /etc/X11/XF86Config-4 (at least thats the option for the nv-driver). Then it's getting but-slow!
  • Games, spreadsheets, word processors, web browser, two shells (gmc and nautilus), digital camera utilities, image editors, cd players, mp3 players, mp3 rippers, development tools, GUI design tools, profiling tools, calendars, address books, palm pilot utilities, text editors, finance manager, mail clients, irc clients, IM clients, ftp clients, system config tools, themes, window manager, panels, applets, as well as the gnome and gtk+glib libraries.

    - - - - -
  • It's libart. Nautilus uses libart to display everything.

    - - - - -
  • Why are you always saying something bad about linux?

    Every single post contains a negative comment about linux. What the hell for? Are you a troll? Jesus, man, you act as if you're employeed by The Beast to detract from linux because, after all, linux is threat #1.

    (chances are you broke "ls" because you did something stupid. Thanks alot for blaming it on the glibc maintainers, you prick)

  • Re:how to get this working if the installer dumps (Score:4)

    by fosh ( 106184 ) on Thursday March 01, 2001 @03:35AM (#393978) Journal
    This used to happen to me all the time in helix-update, red-carpet and up2date. After much pain and suffering, I discovered it was just a slightly broken RPM database. To fix it, just issue the following command:

    rpm --rebuilddb

    Good Luck
    --Alex
  • I just want to point out that your mother doesn't care about the "easyness to program".

    Well of course not, but that's not the point. You don't try to attract programmers to your platform because the programmer market is so large. You want to get programmers building for your platform so that when one of them has some insanely great idea, she builds it for your platform rather than your competitors.

  • It was probably posted so a greater number of people can find it and test it out as it makes its way through the beta stages. Either that or it was a slow day for Slashdot. =)

    --
    Scott Miga
    suprax@linux.com
  • The problem many people have with X are related to slow drivers. If you have an Nvidia card like myself, you really notice the difference between diffenrent drivers.
    X 3.3 is dog slow, X 4 with default drivers is nearly as fast as windows, and with the Nvidia drivers X runs like a dream.
    I hear alot of people bitching about performance issues, but most of them either have vid cards with shitty drivers, or have misconfigured system (e.g. all the people who complain kde is slow because the don't have their host file and hostname setup right).
  • There's a few things to think about.

    OSX only works on new-world Macintosh machines. Are you _sure_ the machine you're trying Nautilus on compares equally? If its an x86 box it needs (a)double the megahertz, (b)128MB RAM. In addition, as has been said before, I'm guessing that OSX takes better advantage of hardware accelleration than X does.
  • Try KDE and you'll never look back

  • What kind of video card do you have? What version of XFree? I find the latest versions of XFree (3.3.x and 4.x) to be very fast.

    X isn't as much of a bottleneck as many people would claim. Likely the problem lies with how some of these apps are programmed, and how they use the toolkit.

    Having a window manager, toolkitk and desktop heavily themed with huge pixmaps doesn't help either.
  • Did you complain about 2.1 being announced. That was just a developement release.
    Molog

    So Linus, what are we doing tonight?

  • Don't submit any bugs to them though - it'll just end up in the "boring message" bucket. At least that's where anything that isn't linux related seems to go.

    It's kinda funny that the Linux nazis (and now they are even Lintel nazis) have come full circle from M$FT and decided that their O/S is the best, and nothing else even exists.

  • Re:nautilus up for the job (Score:4)

    by Skeezix ( 14602 ) <jamin@pubcrawler.org> on Thursday March 01, 2001 @06:27AM (#393987) Homepage
    I don't know which version of Nautilus you tested most recently, but from my experience with running the hourly builds, I have to say Nautilus has become a lot faster. The Nautilus hackers are certainly addressing performance issues. A lot of the major performance tuning will probably have to come post-1.0, but expect Nautilus 1.0 to certainly be usable in terms of performance. Some of the major bottlenecks right now involve gnome-vfs and bonobo, two rapidly developing, yet new technologies. As these frameworks mature, look to see applications such as Nautilus that use them also improve. You can think of Gnome 1.4 as sort of a stepping stone to Gnome 2.0. Gnome 1.4 introduces some new technologies such as Bonobo, gnome-vfs, and the Nautilus architecture. During the development of Gnome 2.0 applications will be ported to the new GTK+ 2.0 toolkit, Bonobo, gnome-vfs, Nautilus, et. al. will be improved upon, and more applications will make use of these new technologies. This means more testing, more patches from more people and a better environment from which to work. If Nautilus is just too slow for you, you can still use gmc--we've included it in the Gnome Fifth Toe as a deprecated, but still available application. Keep trying out the builds of Nautilus, though--It's improving very quickly!
    ----

  • Don't agree. AIX is as standard as it gets

    Sorry, bad example. I haven't followed AIX recently.

    Fix it, don't invent excuses

    That's a bit hard when you don't have $10,000 on hand to purchase the target system that somebody is bitching to you about in an email.


    All your hallucinogen [pineight.com] are belong to us.

  • Re:sounds grate.. but.. (Score:3)

    by Skeezix ( 14602 ) <jamin@pubcrawler.org> on Thursday March 01, 2001 @06:33AM (#393989) Homepage
    If you mean what's new since Beta1, not much. During the Beta cycle we're just fixing bugs, doing QA, and the like. As far as what's new since Gnome 1.2, here you go:

    Some of the new features in Gnome 1.4 include:

    User level

    * Nautilus
    * enhanced display manager
    * better KDE interoperability
    * better support for legacy X applications
    * application launch feedback
    * improved Panel
    * integrated Sawfish window manager
    * Improved help browser and help system
    * Usability and quality improvements throughout

    * Fifth Toe release including a broad collection of apps that run on
    GNOME.

    Developer level

    * gnome-vfs - Virtual file system allowing transparent access to local
    and remote files.
    * Bonobo component model - technology preview
    * xml-i18n-tools - better internationalization and localization tools
    * GConf - Advanced configuration/settings system with notification and
    pluggable back ends
    * Medusa search/indexing system
    * Laguage bindings - C++, python, guile, rep

    The Fifth Toe is a set of applications that are not part of Gnome proper but work with Gnome. They include office applications, games, a few panel applets, utilities, and chat programs.
    ----

  • Re:changed to KDE after years with GNOME (Score:3)

    by JoeBuck ( 7947 ) on Thursday March 01, 2001 @07:34AM (#393990) Homepage

    And if you don't like it, there is always apt-get remove task-kde.

    That won't remove KDE from your system; it will only remove a tiny package that depends on the KDE packages, probably freeing up a few hundred bytes.

  • Exactly. I'm out to get Linux. I wake up in the morning and think, hmm, I haven't flamed Linux today. Look, jackass, I have nothing against Linux. I actually kinda like the system. Still, I don't find any use in being one of the me-too monkeys who go around espousing the greatness of the platform. Linux has serious problems and lots of them. Every OS does. Talking about them is a lot more useful and ignoring them and pretending they don't exist.

    BTW> "chances are you broke "ls" because you did something stupid. Thanks alot for blaming it on the glibc maintainers, you prick" --- right out of Microsoft tech support. I didn't do anything wrong. All I did was run the install script for the package. The actual problem was due to the fact that the package had a bad interactaction with something in the system, and admirably the problem was fixed in a few days. I was not trying to blame the glibc maintainers, I was simply pointing out that shit happens, almost as often on Linux as on Windows (yes! and even BeOS!).
  • Is it me or is embedding mozilla in nautilus just a BAD idea. On my various systems mozilla is far faster native so what is the point
  • I want to know where are you buying your crack. It's really good!

    Have you ever thought about that we do compile on mainstream platforms? Because otherwise we couldn't work on the thing. Build system not working on some particular setup doesn't mean that the build system in general is screwed. Most likely it means that 1) you have some weird ass library 2) screwed up headers 3) too bleeding edge environment.

    From your comments I don't suppose you've ever tried fixing build problems. I do this all the time because I have an alpha. And imagine what, I've never seen most of the code that I try to fix. It's fairly simple to identify the problem and it's usually some weird setup on my part rather then a bug in the build system.

    So guess what. We aren't running into build errors. I guess we're not quality-driven by your meassure. Think about what you are saying. Why would we release something that doesn't build for us, it doesn't make sense.

    Think about how many even just linux platforms there are. I don't have that many partitions and spare machines to try them all. If you don't want to contribute your time, then send me a machine, and I'll make sure it builds on there.

    Plus do note that it takes one, read carefully, ONE person to fix a build problem and send in a patch so that the next beta will build on his system. And then it will work for all those users. If a particular setup does not have enough people who care about gnome compiling, then it is unlikely to get fixed. Way of life. I won't go around fixing build problems on Fufu Linux because I have better things to do. Oh yeah, like coding, you know, that process that produces code rather then to deal with stupid build problems on broken platforms that 5 1/2 people use.

  • KDE 2.1 is news
    KDE 2.1beta3 is not news
    stop posting this gnome crap! might as well just make a box on the side to show this junk.. maybe gnome.slashdot.org ?
  • Yeah, I think the 2D stuff is generalized, but there are a lot of ways to do it, and that's driver related. See this post [geocrawler.com] to dri-devel about what's been accelerated using AGP and DRM accel, and this post [geocrawler.com] on performance with the new r128 driver. Still very very new code, and other posts indicate the numbers may not be totally accurate, but if it is, then it's a good start for much better 2d performance from X.

    "I may not have morals, but I have standards."
  • The beta and release candidates are news. /. has a wide viewing audience and a large percentage of ./ users are Gnome or KDE users. All of the KDE betas made it to /. and why not? The more people try it out and report bugs and do testing, the better.
    ----
  • No? Why not? Listen, replacing X isn't going to be easy. And unless you're going to do it, shut up and stop whining. Instead, THANK the people who have *given* you a Free implementation of the X Windowing System. Got it? Good.

    I always get a bit put off by opinions like this. Just give the guy a break. He merely pointed out that he believed X to be suboptimal for certain tasks. Throwing stuff like ``shut up, be thankful for what you got, we don't need any second opinions on what we create'' isn't really going to help much. The only thing such comments are good for is to draw people away from using open source alternatives altogether. Why is it that many open source coders treats users in much the same way that sysadmins do (i.e., they loath them because users always tend to make their job a bit more tedious).

  • The problem is not X but XFree86, X just draws stuff, it X didn't draw it something else would, and most of the interface problems are being worked on. If you need something faster buy a comercial X server. Also Eazeal is just beta software, they were smart about developing it in that they payed little atention to speed until it was almost done and now they can optimize it. Thats the way you should design software.
  • What's the point, anyway? Ximian has plenty of PAID and EXPERT packagers to deal with these problems with us.

    Just a little tip.

    =)

    Of course if you run Slink like me, you lose big.
  • Ok, but I think he was talking about the G4, not the G3. But anyway, there's that comment by John Carmack: here [slashdot.org]
  • No, this is the result of Intel being on GNOME advisory board :-) (just kidding)
  • GOOD EVENING GENTLEMEN.
    ALL YOUR DEAD HORSE ARE BELONG TO US!

    *die lameness filter, die a horrible flaming death*

  • Believe it or not, I know of SEVERAL projects that released code that didn't compile for them as betas. I thought (based on the comments) that Gnome now had the same kind of problem. If you don't run into build errors, then you are quality driven, as long as you do a compilation test on major platforms before you release.

    Did you read my response at all in detail? We agree on most of the things that I said. I do fix build problems all the time, if they are stupid "Whoops, can't find the path of this header file", or other problems. But when the compiler just won't accept the code, then that's completely different.
  • they'd better be bloody aware of the issues! this is a beta 2, like, something that's being primed for release!

    if it makes it out as a release version with speed and performance like this, it'll be another gnome v1 embarrassment all over again.

    i'm impressed by the functionality and presentation of eazel's work, but i'm doubting their attention to doing things The Right Way.

    matt
  • you obviously have not met my mother...
  • "while Nautilus is very cool, it's almost like they forgot about the issue of speed."

    I believe a wise programmer whose name I forget said "Premature optimization is the root of all evil." The developers probably want to bang out the bugs before sizzling the code.

  • "Try KDE and you'll never look back"

    Hardly. I have gone back and forth between KDE, GNOME, and assorted window managers more times than I can count. Not everyone is going to find KDE to be the be-all and end-all of desktops.
  • My mother uses Windows and doesn't care about KDE. I use UNIX because I do, and KDE doesn't do much for me (neither does Gnome).
  • Yes, but people need to be more modest in their wording. The guy said, "We need something better than X and we need it now."

    Note the words "we" and "now".

    There are plenty of people who would take legitament offense at that.

    Free Software isn't magic. But some people treat as if it is.
  • Subliminal message in your signature? Does it work? ;-)
  • it worked with 2.4.0 when i had it on 7.0, it gave the warning anyway though

Slashdot Top Deals

Things are not as simple as they seems at first. - Edward Thorp

Close