Linked by Eugenia Loli on Wed 29th Jan 2003 00:22 UTC, submitted by Andreas Wasserman
Gnome The Gnome 2.2-RC2 (2.1.91) is released. This is the last test version before the final version is to get released next week. Also, the Gnome Summary of this week is published for your reading pleasure.
Order by: Score:
can't wait
by sirmikester on Wed 29th Jan 2003 00:31 UTC

I love gnome! I can't wait for 2.2 final ;)

Yowza!
by Nick Slaughter on Wed 29th Jan 2003 00:34 UTC

I'll wait for a proper .ebuild with all dependencies and stuff checked before I install it but reading their Bugzilla they have really overhauled it this release, and I've run RC1 since it's release and had no Gnome related problems/bugs at all.

For those uninvited with 2.2 changes here is a (somewhat outdated actually but still good) list thingy w/ screenshots etc :
http://www.gnome.org/start/2.1/

RE: can't wait
by Eugenia on Wed 29th Jan 2003 00:41 UTC

>I love gnome! I can't wait for 2.2 final ;)

You would be more useful to the Gnome project though if you actually install the RC-2 and debug it. If everyone waits for the final release, they will get no bug reports... ;)

what to expect?
by linux_lamer on Wed 29th Jan 2003 00:44 UTC

what's new in gnome 2.2?

RE: what to expect?
by Eugenia on Wed 29th Jan 2003 00:45 UTC

Not a Gnome menu editing tool. ;)

RE: what to expect?
by shawn on Wed 29th Jan 2003 00:51 UTC

doesnt nautilus work for you??

Well...
by Nick Slaughter on Wed 29th Jan 2003 00:51 UTC

How much of an editor do you want? Going to "applications://" in Nautilus provides me with all I need + the fact that you can right click items and choose among a bunch of options there (remove, help, propertise, etc).

How is the KDE menu edited? It was quite some time ago I ran KDE so I can't remember (back when first 3.0 beta came out I think).

RE: what to expect?
by Eugenia on Wed 29th Jan 2003 00:55 UTC

>doesnt nautilus work for you??

No. It is a cumbersome way, not user friendly. "applications//" you say. pfff...

>How much of an editor do you want?

How about true drag-n-drop support for remove/insert, as in MacOSX, huh?

RE: what to expect?
by Eugenia on Wed 29th Jan 2003 00:59 UTC

But of course you can't do that (true dnd on the menus), because on Linux, icons and binaries are not assosiated together. This is one of the reasons why drag-n-drop wouldn't work directly from /usr/bin/ to your Gnome menu and automatically get its icon and everything.

These are the times I say that the whole Linux experience needs to be re-thought and even break multiple compatibilities with older crap, just to retool things to work as they suppose to work on an OS that wants to get to the desktop (as Linus said yesterday) in the year 2003.

Troll as much as you want. I am not changing my mind on the subject.

Pure Gnome/KDE
by Darius on Wed 29th Jan 2003 01:01 UTC

I wanted to ask this in the KDE thread, but didn't get a chance to before it got flooded.

Once Gnome 2.2 comes out, which is the best distro to get 'pure' versions of Gnome/KDE? What I mean by pure is one that hasn't been 'panzored' by some distro maker. Though I understand that a distro maker's touches may actually improve the desktop enviroments, I want to see the 'unmodified' versions so that I can fully appreciate/understand what changes distro makers have made to them.
Which distro will let me do this that is reasonably easy to install and upgrade Gnome/KDE to their latest incarnations?

File dialogs
by Omer Hickman on Wed 29th Jan 2003 01:01 UTC

I was hopeing for a screenshot of new Open and Save dialogs . . .

RE: what to expect?
by smoke on Wed 29th Jan 2003 01:02 UTC

sorry - but applications:// is actually the way - it _should_ work. if you build up another app to just handle menu-editing its just bullsh**t - with nautilus you got the drag and drop support you want. once you know how it works, you wont want to startup some cheesy menu editor anymore - instead you just add launchers/groups/scripts there

RE: File dialogs
by Eugenia on Wed 29th Jan 2003 01:03 UTC

Have they actually put them in the CVS already? They were still designing them and changing them daily just 2 months ago... Not sure if the new file dialogs are in 2.2. If they are, that would be good (at last).

RE: what to expect?
by Eugenia on Wed 29th Jan 2003 01:04 UTC

>sorry - but applications:// is actually the way - it _should_ work
> if you build up another app to just handle menu-editing its just bullsh**t

Sweetheart, did I write anywhere about building another application?? I talked about DnD, not about any new suck a$$ application.

There are two ways to edit menu..
by bsdrocks on Wed 29th Jan 2003 01:04 UTC

There are two ways to edit menu that I know so far, right click mouse on the menu or use Nautilus. I am very happy with right click mouse on the menu, because I always do that in Windows too.

RE: what to expect?
by Eugenia on Wed 29th Jan 2003 01:05 UTC

And when I am talking about DnD, I am talking about it working seemlessly across all the gnome panels, not just the menu.

RE: File dialogs
by bsdrocks on Wed 29th Jan 2003 01:06 UTC

Nope, no change in 2.2.. I think, it's going to be in 2.3 or so. I don't see anything wrong with file dialogs, thought. ;-)

RE: File dialogs
by Eugenia on Wed 29th Jan 2003 01:10 UTC

>I don't see anything wrong with file dialogs, thought

This might help you see more:
http://osnews.redpulse.com/img/1280/gnome4.jpg

RE: what to expect?
by shawn on Wed 29th Jan 2003 01:11 UTC

>No. It is a cumbersome way, not user friendly. "applications//" you say. pfff...

I didnt say I like it:P
I generally use key-bindings for most applications anyhow, then the run dialog or *term for the rest. I dont like to click and hunt.

>How about true drag-n-drop support for remove/insert, as in MacOSX, huh?

What.. browse to /usr/bin and then drag the app to apps folder? I personally dont think it would be any faster. But thats me.

RE: what to expect?
by Eugenia on Wed 29th Jan 2003 01:14 UTC

> What.. browse to /usr/bin and then drag the app to apps folder? I personally dont think it would be any faster. But thats me.

First of all, this is why I say that a lot has to be re-thought regarding "unix on the desktop". Applications (as opposed to services or command line tools) should not be in the /usr/bin/ in the first place. A new system should be in place, where a user will be able to install any application for himself, *or* for the rest of the users as well. Having 7,000 binaries in a single dir, is just not practical on the desktop.

And I am not talking about drag it to the app folder. I am talking about dragging it to the menu directly.

CVSGnome 0.3.9
by oGALAXYo on Wed 29th Jan 2003 01:15 UTC

Updated CVSGnome to build GNOME 2.2 RC can be found here. It's able to build from Tarballs OR CVS depending what you want.

http://gnomesupport.org/forums/viewtopic.php?t=1898

RE: RE: File dialogs
by Omer Hickman on Wed 29th Jan 2003 01:29 UTC

A bookmark ability is really needed in the GTK file dialogs. I do, however, think that the two paned MC like view is best for navigation. I would like to see a real tree widget for the left pane and optional column view with dates, sizes etc. to the right. I think it would be cool if the file dialogs could see the bookmarks set in Nautilus or ROX rather then the space wasting stack of location icons like in KDE and XP.

RE: File dialogs
by bsdrocks on Wed 29th Jan 2003 01:29 UTC

This might help you see more:
http://osnews.re dpulse.com/img/1280/gnome4.jpg


Oh, people want like this feature what KDE and Windows have? That's fine with me, I always use drop-menu instead touch the side option on Windows. But, I agree it would be looks more professional and pretty if Gnome change the file dialogs.

RE: what to expect?
by johnG on Wed 29th Jan 2003 01:49 UTC

smoke wrote:
> sorry - but applications:// is actually the way - it
> _should_ work. if you build up another app to just
> handle menu-editing its just bullsh**t - with nautilus
> you got the drag and drop support you want. once you
> know how it works, you wont want to startup some cheesy
> menu editor anymore - instead you just add launchers/
> groups/scripts there

Ahh... and there's the hook. "Once you know how it
works. Maybe there's a more obvious way to do it...?

Eugenia replied:
> Sweetheart, did I write anywhere about building another
> application?? I talked about DnD, not about any new
> suck a$$ application.

Exactly.

> And I am not talking about drag it to the app folder.
> I am talking about dragging it to the menu directly.

Doh! You just lost me.

The most sensible way to do it is very close to the way MS does it.
You need a directory called ~/gnome_menu (or somesuch). In that are
subdirectories: Extras, System_Tools, System_Settings, Games, etc...
One for each label you want to show up in the menu.

Using nautilus, right click and drag apps from /usr/bin (or wherever)
and drop them into these folders choosing to create symlinks. Bang.
They should then show up in the menus.

And *that*, my friends, is the way it should work.

eugenia
by vince on Wed 29th Jan 2003 01:55 UTC

you may not have perferct english grammar... but your wit is dead on.

RE: what to expect?
by Eugenia on Wed 29th Jan 2003 01:58 UTC

There is no reason why the menu should be in a directory. It could be XML files, as it is today.
Having them in a dir, and then DnD from a huge dir (like /usr/bin/) requires not only to make manual work (remember, the icons are not set automatically either and you will still need to answer a dialog if you want to move or copy or link the file) but it requires the user to _know_ that there is a directory called gnome_menu, somewhere hidden maybe in a bigger directory structure. And then, the user will have two representations of the menu, one in his gnome menu and one inside Nautilus. And that doesn't make sense, because it is duplication and for a computer agnostic user is not logical the fact that his gnome menu somehow can be viewed within another application.

DnD is the best option for menus, the way BeOS and MacOSX does it (actually, BeOS has the best of both worlds - a directory with all the menu entries somewhat "hidden" from public eyes on /home/config/applications/ I think, and also supports DnD as of R5).

any file select prototype link?
by m on Wed 29th Jan 2003 02:01 UTC

I can't find any actual file selection prototype for GNOME2 (I know of older ones for GNOME1). This is an interesting thread from July 2002 about file dialogs and customizable toolbars --> http://mail.gnome.org/archives/gnome-devel-list/2002-July/msg00001....

It seems there isn't any prototype implemented yet. Quoting Pennington: "No, no one has started yet. There is some work on an icon list in libegg."

RE: any file select prototype link?
by Eugenia on Wed 29th Jan 2003 02:03 UTC

There are many screenshots to be found from the file selector prototype on previous issues of the Gnome Summary. Just check the archives of 1-3 months ago, and you will find them.

RE: what to expect?
by shawn on Wed 29th Jan 2003 02:05 UTC

>First of all, this is why I say that a lot has to be re-thought regarding "unix on the desktop".

Maybe for people that just want it to work. But then why not use an os geared toward that?

>Applications (as opposed to services or command line tools) should not be in the /usr/bin/ in the first place.

Why not? I honestly dont see a problem with it.

>A new system should be in place, where a user will be able to install any application for himself, *or* for the rest of the users as well.

Hmm...
# su
#./configure && make && make install
# rpm -Uvh *.rpm
works fine ... not user friendly as a wizard though
Let not get into changing the Unix security model in favor of Windows.

> Having 7,000 binaries in a single dir, is just not practical on the desktop.

I hope your joking.

>And I am not talking about drag it to the app folder. I am talking about dragging it to the menu directly.

sorry thats what i meant

RE: what to expect?
by Eugenia on Wed 29th Jan 2003 02:12 UTC

>But then why not use an os geared toward that?

Because none of these "desktop" distros do the necessary steps. They are small companies with very few employees, they don't have the money and resourers to recreate the Linux *platform* geared for the desktop. The only company that has money and partners to help it, is Red Hat. The rest struggle, there is no way we can see the kind of innovation I am talking about from the rest.

>Why not? I honestly dont see a problem with it.

Because you don't want to try to find your photoshop binary among a gazillion other command line utils and other crap stuff that you usually find in there. The app binary dir should be clean and well thought.

>Let not get into changing the Unix security model in favor of Windows

No my friend. We change the unix model in favor of the race for the dekstop. Linus said yesterday that he wants his linux to get to the desktop. Well, I just provide him with some clues.

The example you gave me, only works for instrallation ONLY if you are root. How about installing this app, just for you and not the rest of the users?

>I hope your joking.

i am not. usr/bin/ is a mess. There are hundrends of files in there. It is just not practical to have user apps there and then use them to put them easily in menus. It is just not practical. Remember: we are trying to do things that do not require us to use the terminal.

ok, got it
by m on Wed 29th Jan 2003 02:14 UTC

GNOME Summary - 2002-09-29 - 2002-10-05
5. New GNOME File Selector? ( http://developer.gnome.org/news/summary/2002_September29-October05.... )

Prototype ---> http://home.wanadoo.nl/sbm/
It looks great if you ask me, next Red Hat beta?

better than the older one
by m on Wed 29th Jan 2003 02:25 UTC

this other older one doesn't appear to have bookmarks:
http://snorp.coreyo.net/~snorp/fileselector-test.png

RE: ok, got it
by Omer Hickman on Wed 29th Jan 2003 02:41 UTC

I like it. I think that the icon on the Save dialog should be DnD enabled for RISC/ROX style drag and drop saving.

RE: what to expect?
by shawn on Wed 29th Jan 2003 02:48 UTC

>>But then why not use an os geared toward that?

>Because none of these "desktop" distros do the necessary steps.

Im talking about a different OS, not a different distro.

>Because you don't want to try to find your photoshop binary among a gazillion other command line utils and other crap stuff that you usually find in there. The app binary dir should be clean and well thought.

So instead of trying to find it in /usr/bin with the other 7,000 _files_ you can search through /usr/<applications> among the other 6,999 _folders_??

I just dont see the big deal.

>No my friend. We change the unix model in favor of the race for the dekstop. Linus said yesterday that he wants his linux to get to the desktop. Well, I just provide him with some clues.

Thats all fine and dandy. Since he is responsible for the kernel. I dont see how he will influence the applications.

>The example you gave me, only works for instrallation ONLY if you are root. How about installing this app, just for you and not the rest of the users?

Greedy arent we:) Install into your home directory I suppose.

> i am not. usr/bin/ is a mess. There are hundrends of files in there. It is just not practical to have user apps there and then use them to put them easily in menus. It is just not practical. Remember: we are trying to do things that do not require us to use the terminal.

Does it really matter if your installation program does its job?
But wait selecting create shorcut- browse - /usr/bin/ - scroll down to p - ah there it is <photoshop> - is too damn hard. Im not convinced

No reason
by William Clifford on Wed 29th Jan 2003 02:54 UTC

> There is no reason why the menu should be in a directory. It could be XML files, as it is today.
> Having them in a dir, and then DnD from a huge dir (like /usr/bin/) requires not only to make manual work

Well if there was an XML based filesystem this could probably be done. And even if there is such an FS these environments are still going to need some kind of registry-like system to associate icons with applications for dealing with filesystems without such abilities.

And actually having the menu be a directory isn't, necessarilly a bad idea. A directory is just a file after all and the OS knows how to talk to directories really speedy. The DnD system is going to have to be smart. When fidding with a menu, you aren't moving files from one place to another, you're just pushing symbolic links around. Personally I would just make something registry-like which dumped it's user configurations into ~/.gui or something.

I do not see the need for more mucking with the FHS. Especially for something like this. The *nix file hierarchy has been mucked with too much as it is.

A mess
by William Clifford on Wed 29th Jan 2003 03:00 UTC

Also:

> i am not. usr/bin/ is a mess. There are hundrends of files in there.

"Hundreds"?! Mere "hundreds"? You aren't trying hard enough.
:)

$ls /usr/bin |wc -l
1705

RE: what to expect?
by Eugenia on Wed 29th Jan 2003 03:01 UTC

> So instead of trying to find it in /usr/bin with the other 7,000 _files_ you can search through /usr/<applications> among the other 6,999 _folders_??

Hehe, not at all. You can either have pre-created directories that are specific for video, multimedia, productivity etc OR, you can do it my way, which is an attributed file system which keeps track of what gets installed, where, how many times it was launched etc. And then you have a special app launcher application (not a menu with a zillion submenus) that shows you several different choices:
1. You can browse apps by category (visit www.bebits.com and check their system)
2. You can browse apps by popularity (most launched)
3. You can browse apps by last installed
4. You can browse apps by most recently used

There should not be more than 10 apps listed for cases 2 to 4.

Now, THAT works. For everyone. And while it would be better the binaries to not all be on /usr/bin/, it would still work if they were there. But for uninstallation purposes, it would be better to have a special folder for "user" graphical apps.

>Im not convinced

I am. The current model is not nice for me. Loading on Nautilus or Konqueror the /usr/bin/ takes about 10-12 seconds here! That's damned too slow (and a no-no situation for the idea I present up there), because there are too many files in there! And then, you have to actually FIND the app name, scrolling a zillion files. Hardly intuitive.

So, at least I have some ideas on improving the damn thing. I have worked on it and I have even mockups.
You seem to represent the old school "don't touch my unix" kind of thing. Which if you continue having this attitude and not open your mind to alternatives that are FOR the desktop, then the Linux is going nowhere for that desktop. Currently, Linux is a great small server, but it is hardly any innovating in the dekstop/DE side. It is a copycat of what we already got. No innovation at all. I am proposing ideas to make changes that can be at least different. Who is listening though?

RE: what to expect?
by linux_baby on Wed 29th Jan 2003 03:06 UTC

>But then why not use an os geared
>> toward the desktop

Windows started life as DOS, which , from the viewpoint of comtemporary OSes, was definitely not a "desktop" system. The entire windows line evolved from that humble begining. And look how many years it took.

OS X, too, is built on top of unix. Surprise! We must not forget, folks, that progress is cumulative.

>> These are the times I say that the whole Linux experience needs to be re-thought and even break multiple compatibilities with older crap, just to retool things to work as they suppose to work
<<

Maybe. But in the real world, that kind of radical change rarely happens. Progress is almost always incremental. You take it one small step at a time. In my opinion, the linux desktop is already making huge strides. Linux has gotten to the point where ordinary folks can actually do work with it. I personally don't see any need for radical change.

Oh, and there are many ways to change things. Writing RFCs is not one of them!

Re: shawn
by Darius on Wed 29th Jan 2003 03:07 UTC

But wait selecting create shorcut- browse - /usr/bin/ - scroll down to p - ah there it is <photoshop> - is too damn hard. Im not convinced

Of course you're not, because you like the Linux way of doing things, which is not really desktop friendly.

On my computer, there are about 25 different folders in Program Files, with God only knows how many files in each one. I would much rather search through 25 folders to find what I'm looking for than through thousands of files in a single folder. Hell, by your logic, they should just dump every damn file of the OS in a single directory, and then you could just scroll to find the one you're looking for.

But the bottom line is, Linux lovers want to know what it would take to get Linux on the desktop in full force, and so we tell them, and they stick their noses up at us because what we expect of a desktop OS is not the same as what that expect. To us, using Linux is like a man trying to read a romance novel - it just doesn't make any sense at all.
So, the choice is really easy .. either make Linux user friendly (not Unix friendly) or remain a niche OS.

RE: what to expect?
by Eugenia on Wed 29th Jan 2003 03:09 UTC

>Progress is almost always incremental. You take it one small step at a time.

Not for Apple. They took BSD and Mach and they did their thing. The way it made sense for them. I wish someone would do the same with Linux or FreeBSD and X. They get the kernel, destroy compatibility ANYWHERE that it is _needed_ in order to INNOVATE and go from there.
Creating similar, compatible distros and throw 500 packages in them and sell them, is hardly innovation. It is just a living for me.

>Oh, and there are many ways to change things. Writing RFCs is not one of them!

I won't provide anything else other than mockups, ideas and points. I don't have the need to do so, neither the drive to write code anymore. It is up to the developers to fix their own applications.

RE: what to expect?
by Eugenia on Wed 29th Jan 2003 03:13 UTC

>Writing RFCs is not one of them!

What I already do here, is already _enough_. I used to do UI design for a living, so that's my best quality, so that's what I am offering. For free.

I stopped reading my French (I am trying to learn french since last week) just to participate in this discussion and give the X DEs pointers and ideas.

RE: RE: what to expect?
by Omer Hickman on Wed 29th Jan 2003 03:14 UTC

The AppDir spec for ROX is very flexable, keeps all of a program in a single directory that is represented as an icon in the file browser. AppDirs contain the src and compile/optimize the binary the forst time its run. Also an AppDir program can be 'installed' localy or system wide depending if its under /usr/apps/ or under a user's home.

A great solution to the /usr/bin/ issue ;)

Well......
by Martin on Wed 29th Jan 2003 03:24 UTC

Ok... Let's talk about it...

so there is to much file into /usr/bin .. well... I think whe should compare that directory with c:winntsystem32 ... and then ask ourself: which one is the biggest mess???

Also, the files into /usr/bin have a clear name, easy to understand. hoo.. and by the way, why should I search for winword when I want to load word?

ciao!

RE: Well......
by Eugenia on Wed 29th Jan 2003 03:33 UTC

> so there is to much file into /usr/bin .. well... I think whe should compare that directory with c:winntsystem32 ... and then ask ourself: which one is the biggest mess???

Unix's of course!!
The system32 is a SYSTEM's directory. We are talking about user applications! System32 does not have user applications. The equivelant for Linux is this:
/bin/
/lib/
/usr/bin/
/usr/lib/
/usr/local/lib/
/usr/local/bin/

As you can see there are SIX directories on Linux, that do the same job as c:windowssystem32 does. And as if this was not enough, they throw the USER applications on /usr/bin/ along with all the rest of the crap that the user 90% of the times, doesn't need to know about.
/usr/bin/ was designed FOR the user application, but with the years, it has become a big piece of mess and it really needs cleaning up. Or do it the Apple OSX way.

So, to answer your question: The biggest mess remains Linux. Not Windows, in this situation.

>Also, the files into /usr/bin have a clear name, easy to understand. hoo

Same goes for the applications on c:Program Files. What's your point?

>and by the way, why should I search for winword when I want to load word?

Because no one is searching for the binary of Word. Is always there, everpresent, either on the menu, or on the program files dir, or by just double clicking a .doc file, or when you right click to a .doc file. In all my life, I have never had the NEED to search for the name of that binary. So, even if they call it Eugenia'sWord, it would still not matter. While it would certainly matter under Linux, because I would need to _search_ for it. But on Windows, there is not such need for this.

Next time, please do your homework before you start talking about usability issues.

Wow
by Chris Parker on Wed 29th Jan 2003 04:20 UTC

GNOME is really kicking ass. I thought that it was dead a year ago, but they have come a long way.

RE: Eugenia
by Omer Hickman on Wed 29th Jan 2003 04:27 UTC

I do also think that non-system programs should go some place like /opt/<appname>/ and be clearly seperate from the system level. But with advanced packaging solutions abstracting the details of application installation what does the install directory really matter? The .desktop standard for application metadata will also help a lot with this problem - basicly the same as Window's menus.

RE: RE: what to expect?
by fraxtar on Wed 29th Jan 2003 04:29 UTC

> You can either have pre-created directories that are specific for video, multimedia, productivity etc ...
Let's keep /usr/bin and then let's create a directory systemwide where links to this apps are classified in the way you satated above. And then let the user have the choice of creating links from this directory or directly from /usr/bin. This directory must be easily aviable for any desktop user.

Filesystems
by Chris Parker on Wed 29th Jan 2003 04:34 UTC

I have read through the posts and, though I agree with Eugenia that there is too much under /usr/bin in most Linux distros, the current Unix filesystem is great is you have multiple users on one system.

I am not going to go into great detail on the history of Unix filesystems and what each directory means, but the Unix filesystem is tried and true and is amazingly scalable if used right. I work on systems that have hundreds of users connected to each, each user with a different account, and each machine with multiple levels of administration. There are also, with the users, multiple developers writing code in their own environments. I could not see how you could do this on any other environment.

As far as navigation around Unix, this is where abstraction should come in. The user really shouldn't have to even know there is a filesystem, or learn the hierarchy, to be able to use a computer. OSX does a pretty good job at this, while still maintaining a robust scalable Unix backend.

/usr/bin
by theBare on Wed 29th Jan 2003 04:35 UTC

I, for one, would rather have all my executables in one or a couple places rather than having a path that is a several thousand characters long. These are my options as command-line-using throwback...

Hmmm... I can see it now...:

C:/Program Files/mkdir
C:/Program Files/ls
C:/Program Files/grep
C:/Program Files/gcc
C:/Program Files/sh

Re: Desktop
by linux_baby on Wed 29th Jan 2003 05:13 UTC

>> I stopped reading my French (I am trying to learn french since last week) just to participate in this discussion and give the X DEs pointers and ideas.
<<

That's why OSNEWS is bublling again ;) . You can see the obvious difference. Anyway, I thought you had come back fulltime.

RE: RE: what to expect?
by shawn on Wed 29th Jan 2003 05:16 UTC

> Eugenia
>You seem to represent the old school "don't touch my unix" kind of thing. Which if you continue having this attitude and not open your mind to alternatives that are FOR the desktop, then the Linux is going nowhere for that desktop. Currently, Linux is a great small server, but it is hardly any innovating in the dekstop/DE side. It is a copycat of what we already got. No innovation at all. I am proposing ideas to make changes that can be at least different. Who is listening though?

> Darius
>But the bottom line is, Linux lovers want to know what it would take to get Linux on the desktop in full force, and so we tell them, and they stick their noses up at us because what we expect of a desktop OS is not the same as what that expect. To us, using Linux is like a man trying to read a romance novel - it just doesn't make any sense at all.
So, the choice is really easy .. either make Linux user friendly (not Unix friendly) or remain a niche OS.

Please dont categorize me. I honeslty dont care if linux makes it on the desktop. Whatever making it on the desktop means. I dont represent the old school "don't touch my unix". I represent it works for me and happen to enjoy my computing experience crowd(independent of OS). If you cant swallow that then tough.

I always hear about these snobby Linux users. I havent meet one yet.

RE: Well......
by bsdrocks on Wed 29th Jan 2003 05:22 UTC

Unix's of course!!
The system32 is a SYSTEM's directory. We are talking about user applications! System32 does not have user applications. The equivelant for Linux is this:
/bin/
/lib/
/usr/bin/
/usr/lib/
/usr/local/lib/
/usr/local/bin/

As you can see there are SIX directories on Linux, that do the same job as c:windowssystem32 does. And as if this was not enough, they throw the USER applications on /usr/bin/ along with all the rest of the crap that the user 90% of the times, doesn't need to know about.


Do you have any idea if you prefix gimp to /usr/local/gimp, Apache to /usr/local/apache and etc? The result would be..

/bin/
/etc/
/lib/
/usr/bin/
/usr/lib/
/usr/local/gimp/
/usr/local/gimp/bin/
/usr/local/gimp/etc/
/usr/local/gimp/lib/
/usr/local/apache/
/usr/local/apache/bin/
/usr/local/apache/etc/
/usr/local/apache/lib/
/usr/local/mysql/
/usr/local/mysql/bin/
/usr/local/mysql/etc/
/usr/local/mysql/lib/
goes on..

Now, the questions is which worst? Well, it is making a lot worst by a lot of duplication of effort and wasted directory entries. Not to mention, your PATH becomes extremely long, or you end up with a centralised tree structure full of symlinks. I call it non-standard, so FreeBSD's hier(7) and FHS agree too.

/bin/
/lib/
/usr/bin/
/usr/lib/
/usr/local/lib/
/usr/local/bin/
/usr/X11R6/lib/
/usr/X11R6/bin/

It makes perfect sense.

/usr/bin/ was designed FOR the user application, but with the years, it has become a big piece of mess and it really needs cleaning up.

I am sure, you use FreeBSD as firewall, so check man 7 hier. The /usr/local/ and /usr/X11R6/ (for X apps) should be the directories that where SysAdmins install the apps. The /usr/ is for the system that came with by default. Your idea about change the file system hierarchy will taking a quiet lot of time to finish and change a lot of stuff. Don't forget, *nix have a lot of libraries, apps and etc, so it's more pain in ass to check each directories, just to edit the configure files or else.

The Killer Desktop...
by William Clifford on Wed 29th Jan 2003 05:24 UTC

...will be an unholy hybrid of Sawfish, Emacs, and Rox. We'll call it Zod. "Kneel before Zod!"

no need for PATH
by dealing_death on Wed 29th Jan 2003 05:43 UTC

theBare, bsdrocks, & others are missing the point. There is no need to move /usr/bin & friends. OSX does not. The model works well for CLI apps.

What needs changing is the method of accessing GUI applications. Noone needs a PATH for GUI apps. OSX gets it right by using an /Applications directory. It also bundles each app into a single icon, for easy launching, installation and uninstallation (although older Carbon apps do not always do this).

IMHO Windows falls down here too; C:Program Files is a mess, athough not as big as /usr/bin. MS even tries to prevent users from mucking about in that directory, telling them to use the Start menu and Add/Remove programs instead.

Creating greater levels of abstraction on top of the FS to make nice menus and easy installation adds a lot of unnecessary complexity, when the FS could be simplified and used directly.

LinuxStep
by mjang on Wed 29th Jan 2003 05:55 UTC

The system32 is a SYSTEM's directory. We are talking about user applications! System32 does not have user applications.

Hearts, Solitaire, MSPaint, Calc, etc are all in system32. ;)

Seriously though, Eugenia, have you taken a look at LinuxStep ( http://www.linuxstep.org/ )? I read their mailing list awhile back and I think I remember them wanting to apply a more user-friendly directory structure and make other changes to some of the user-unfriendly conventions as well. The site has been stagnant for awhile, but the lists still see some traffic.

Could we maybe get an interview?

RE: The Killer Desktop...
by Omer Hickman on Wed 29th Jan 2003 05:56 UTC

LOL!!!

RE: no need for PATH
by Eugenia on Wed 29th Jan 2003 05:56 UTC

>What needs changing is the method of accessing GUI applications.

Exactly.

Re: bsdrocks
by Darius on Wed 29th Jan 2003 05:57 UTC

/bin/
/lib/
/usr/bin/
/usr/lib/
/usr/local/lib/
/usr/local/bin/
/usr/X11R6/lib/
/usr/X11R6/bin/

It makes perfect sense.


Um, makes sense to who? I don't give a damn what planet you're fom .. when you see those manes for the first time, you're not going to have any idea what the hell it means. ESPECIALLY usr/X11R6 ...
Even if you know what X11 is, what th f**k is R6? It's certainly not apparent by the directory name.
Now, I'm not saying any of this to defend anything that Windows does differently (or similarly), but when you say the above directory names/structure makes sense, that's a pretty good indication to me that you need to lay off the crackpipe ;)

RE: RE: no need for PATH
by Omer Hickman on Wed 29th Jan 2003 06:03 UTC

>>What needs changing is the method of accessing GUI applications.

>Exactly.

The specifications on http://freedesktop.org for the .desktop file is a good start in this direction.

Re: bsdrocks
by bsdrocks on Wed 29th Jan 2003 06:08 UTC

ESPECIALLY usr/X11R6 ...
Even if you know what X11 is, what th f**k is R6? It's certainly not apparent by the directory name.


No comment, I agree with you. At first, I wonder why the hell they called it as X11R6 rather than X11. But, it doesn't matter if you rename it to X11 or whatever. It still makes sense to keep GUI apps seperate from non-GUI apps.

that's a pretty good indication to me that you need to lay off the crackpipe

Ok, sounds good! Are you buying? ;-)

Oh btw: dealing_death and Eugenia, sorry I guess I am still missing the point. Because, I never have touch and use MacOS X, BeOS or whatever what OS that have you like. So, stuff is perfect sense to me. :-) If you have any urls about it, show it me to see if it will clear the cloud in my head.

Non-Distro
by Nathan O. on Wed 29th Jan 2003 06:11 UTC

I agree that while GNU/Linux and UNIX are great, they're in dire need of a workout if they wanna be desktop players. They're set up in a very good way, as far as servers go. I think someone would do well to take the Linux kernel, the GNU utilities, and X, do whatever they wanna do to them, and put it out as a whole new thing- not a new distro, but a new linux, mostly incompatible with today's Linux, but not untirely difficult to port to.

Ya know, something like that *is* legal.

Of course it is a big undertaking. Hey, I smell a new community project brewing ;) . Another job for SourceForge, maybe? "It's too much for anyone to get done" sure would be a lame answer from the community that has made Linux what it is today.

RE: RE: no need for PATH
by Eugenia on Wed 29th Jan 2003 06:15 UTC

>The specifications on http://freedesktop.org for the .desktop file is a good start in this direction.

http://www.freedesktop.org/standards/desktop-entry-spec/desktop-ent...
First of all, this is not XML (much more prefered). Second, I find the OSX way much better than this mess that the FreeDesktop suggests. You see, a .desktop file will be stored somewhere in your home, and it will launch a binary somewhere else and it will load a png icon somewhere else. If your admin deletes the binary, you are left with a non-working .desktop.

MacOSX and Windows, still do it better. In fact, OSX does it even better than Windows in this regard. The "configuration" file for the binary is inside the package (the whole app is one big file, which in reality is a package of files) and the equivelant .desktop file is an XML file. And if you delete the binary, you delete its .desktop and icon automatically, as all these live inside the package you just deleted.
On Windows, some of this infromation live inside the binary and some other info lives in the registry.
On BeOS, some lives in the binary file, and you could populate more information via its attributes feature found on its unique filesystem.

But on Unix, because you have all this 30 year legacy behind you, you create more and more hacks. That .desktop thing SOMEWHAT HIDES the problem, but it does NOT solve it. And it has its own issues in the first place. This supposed to be a "new solution" and it is still not better than the 5 year old BeOS, 7 year old Windows and 3 year old OSX.
Who talked about innovation in the linux desktop? None? Ah, ok.

Peace.

Re: bsdrocks
by Eugenia on Wed 29th Jan 2003 06:17 UTC

>use MacOS X, BeOS or whatever what OS that have you like

Believe it or not, I am not a huge fan of OSX. OSX has other issues. ;)
OSX has fixed most user-important stuff, but they have other shit waiting to be fixed.

BeOS was good, could be better. But it is still pretty good. It is free to download, it is only 50 MB. Give it a try and if you have a problem, let me know and I will help you setup it.

RE: Non-Distro
by Eugenia on Wed 29th Jan 2003 06:22 UTC

Nathan O. you indeed "got" what I was saying. We need no new distros. We need innovation. We need a project that takes the kernel, gnu stuff, x and kde/gnome libs and change them in as many ways are _necessary_, breaking as many binary or other compatibilities of any kind as _necessary_ to make sure that you create a legacy-free (but *still* posix compliant) OS, that can match up OSX in ease of use.
Apple did it. They took a unix and while they are still posix compliant, they changed so many stuff, because it made sense to do so, for their customers. This is what it needs to be done wiht Linux as well. It IS a big undertaking, we are talking about the design of a new OS, but based on existing tools with modifications, so instead of taking 10 years, it should not take more than 2. ;)

Re: bsdrocks
by bsdrocks on Wed 29th Jan 2003 06:33 UTC

Believe it or not, I am not a huge fan of OSX. OSX has other issues. ;)

Hehe, I know what you mean. ;-) I love M$ for made Office product, but I dislike M$ for create Windows. :-P

BeOS was good, could be better. But it is still pretty good. It is free to download, it is only 50 MB. Give it a try and if you have a problem, let me know and I will help you setup it.

I already downloaded that BeOS5 PE MaxEdition 2.1, but I just need to delete Linux partition and install BeOS on family box. It will be dual boot between WinXP Home and BeOS, but what kind of boot manage would you recommend?

Resource forks
by Strike on Wed 29th Jan 2003 07:00 UTC

Eugenia, what you are proposing would best be done if resource forks were supported in the ELF format natively (which, afaik, they aren't). So, it's not a DE problem, it's a binary format problem.

I, personally, think that the .desktop format is fine. XML would have been better, but as is it can do everything you've said if coupled with good package management.

RE: Resource forks
by Eugenia on Wed 29th Jan 2003 07:03 UTC

>So, it's not a DE problem, it's a binary format problem.

I know. This is why I suggest you scrap the existing legacy and create a linux experience that works for the desktop, by making as many changes are needed.

Wow...
by Bill on Wed 29th Jan 2003 07:32 UTC

Talk about getting far afield... by the time I read the previous comment, I had to go back and reread what the actual article was about...

For what its worth, I agree with Eugenia 90%. We need /Apps or at least /usr/bin/Apps for GUI stuff.

Darwin is to OS X...
by Nathan O. on Wed 29th Jan 2003 07:34 UTC

MacOS X is just Darwin with a lot of heavy customization, no? So if someone were to take Linux and do the same thing...

Seriously, is anyone here interested in participating in such a project? I've only taken a couple basic C++ classes myself, and am not much of a programmer, but hey, I'd love to do what *I* could for such a project! So yeah, concensus, how many people here, active and posting, would like to be involved in such a project? For that matter, how many people wouldn't / don't think they could contribute, but whould love such a project?

Just a thought, but I'd love something that could fit on a mini-CD. I love those things! And then maybe another ISO made for a big CD with extra apps. Aside from mini-CDs being neat, a smaller target size always keeps out the cruft! ;)

RE: Darwin is to OS X...
by Eugenia on Wed 29th Jan 2003 07:41 UTC

And of course, use something like bz2 or rar for compression for the *custom* package management tool for your new OS, and you will be able to fit in 1 CD apps that need 2 CDs under Linux with conventional packaging methods.

I would like to see such a project, but I am afraid that without a person leading the UI and user experience, and most importantly, the developers to do _exactly_ what the ui person asks, the project would be "just another hacking experience". You see, the problem with today's DEs is also that the devs don't listen to the UI people (I know that this is the case in Gnome; I was told that from a Gnome person). So for that project, the UI/User experience person should be someone that others lean on.

okay
by c on Wed 29th Jan 2003 07:47 UTC

Don't know 'bout y'all, but I've been giving this some thought over the years. The directory heirarchy is excellent for managing an OS, all user data and just about anything. In fact in unix everything is a file. So what I recommend is a system designed around forward and backward compatibility, where incompatibilities are hard linked and require specific packages.

/usr/bin/XFree86-4.2.0
/usr/bin/XFree86-4.3.0
/usr/bin/XFree86 -> XFree86-4.3.0
/usr/X11R6 -> bin/XFree86
/usr/man -> doc/man
/usr/doc
/usr/doc/html
/usr/doc/info
/usr/share - for extra data
/usr/icons
/usr/icons/nautilus/themeblablabla-left-arrow.png
/usr/pics/Wallpapers
$HOME/Wallpapers -> /usr/pics/Wallpapers and set as the default desktop background ( I set mine as a collection of nice gnome/kde backgrounds for each of my 8 vts to choose from )
/usr/pics/gif89a or tif or bmp for unique files
/usr/av - for system/app sounds and multimedia
/pictures -> /usr/pics
/audio - user audio content
/video - video content
/html - perhaps local webcache or a symlink to /var/www/html

Store metadata, possibly in xml, about a heirarchy of symlinks in each user's home directory:

$HOME/.startmenu/Programs/
/Applications/Notepad -> /usr/bin/gedit
$HOME/.startmenu/Settings

The metadata could easily be stored in $HOME/.startmenu/.metadata and tell the system not to read hidden files as apps. Then if an application doesn't have any metadata, but was just dragged into the start menu it would get the default icon but could easily be modified later by the user, such as for DnD operations.

If no .startmenu directory exists it can create a new one by reading a default /usr/.startmenu or /etc/.startmenu. But I would not recommend splitting the default apps and user apps like NT2k did. A user should have full control over the applications and the layout of their menus.

Drag and drop becomes easy, a quick symlink or copy of a symlink and launch a program to add an entry for its metadata. Installing packages can add the metadata for their apps to include icons, etc. The system could even use icons from /usr/icons/startmenu that match the name of the symlink by default.

I think startmenu is a silly name, and some of this needs expanding upon, but that will probably be similar to how I do things when I get around to it.

worse is better
by m on Wed 29th Jan 2003 07:49 UTC

( http://www.jwz.org/doc/worse-is-better.html )

That is the so called "New Jersey" approach so carefully followed by the Unix creed, a complete consistent solution is not important, what it is most important for Unix and the likes is to have any half baked very simple to implement solution (it doesn't matter if the interface is hairball-complex for the user) that spreads like a virus. So if mutants don't interfere, most probably there will be something like .desktop on Linux





Linux Desktop OS
by Arto on Wed 29th Jan 2003 07:49 UTC

>>So, it's not a DE problem, it's a binary format problem.

>I know. This is why I suggest you scrap the existing legacy >and create a linux experience that works for the desktop, by >making as many changes are needed.

But all this just complicates things more and more.

I believe that you know that you are demanding a bit too much to get all this accepted into standard Linux kernels and distros, or the *BSDs (which don't have DEs, except those provided by third parties).

So, you end up with a partial rewrite of the whole OS for Linux, scrapping ELF, scrapping this, scrapping that, making new things and so on.

Then what do you have, out comes new GIMP 2.0, Mozilla 2.0 or whatever, for Linux. Uh-oh, which Linux, the new rewrite, or the old one. The program won't work for both.

I don't see what the idea is of making such a rewrite on top of Linux kernel. While Linux kernel quite frankly is a pretty nice piece of work, why is it so important to build the new things on top of it? And why is it important to build and rebuild on top of the UNIX-world at all.

Just hack up a complete new OS, or use some existing good desktop OS, is what I say.

Vector Linux . . .
by Omer Hickman on Wed 29th Jan 2003 07:51 UTC

That Vector Linux that was reviewed a few articles back sounds like a good start to a less-is-more Linux for desktop users ;)

I know that a project is under way to create a Linux that is ment for running ROX and use AppDirs as its native application packaging system. AppDirs illiminate the need for "resource forks" as the entire directory is treated as a unit. It may also be interesting to make AppDirs a single file by using VFS to access an archive as a directory.

A package manager like RPM would still make sense at the system level and a first time "install" script in each AppDir could interface with a package manager tool to fetch dependencies APT style.

RE: Linux Desktop OS
by Eugenia on Wed 29th Jan 2003 07:57 UTC

You have misunderstood.
When a new Mozilla and Gimp comes out, an afternoon's work should be enough to "port" them to the new system.
The system we recommend _is_ a linux-based system, with X, and KDE-libs (but not with kicker or the KDE desktop as you know it) and with Gnome libs and GTK+ (but not wiht Nautilus and Gnome panels the way you know them). It is a new system, it plays with "new rules", it doesn't have legacy (while remains POSIX), and introduces a lot of new things differently, that would make the experience better.

But by doing all that, does NOT MEAN that you break source compatibility. You might indeed break a few things here and there, but overall, porting a GTK+, X or Qt app to the new system should be TRIVIAL.

So, your argument does not hold up. You haven't understood what we are saying. We say to build a Linux experience that works for the joe user, but based on existing tools and toolkits. Porting gui apps should be trivial, EVEN if the whole system and desktop might look and interact differently.

System directory structure.
by Omer Hickman on Wed 29th Jan 2003 07:58 UTC

What do the specifics of the system level directories matter to the end user if some automagical system like APT deals with where things are put?

more
by c on Wed 29th Jan 2003 08:01 UTC

With symlinks if you are careful about using relative paths instead of abolute paths you can easily pull tricks like mounting /usr/bin from another system or flat out copying entire applications over a network using sftp/scp/ssh or whatever floats your boat. Could all be scripted into the package management system. I think P2P is the best way to distribute updates and Apps.

With the system I meantioned above you could even use metadata to describe apps that were symlinked to a lUFS mount from another system and ran chroot in that environment, for example.

RE: Vector Linux . . .
by Eugenia on Wed 29th Jan 2003 08:03 UTC

> A package manager like RPM would still make sense at the system level and a first time "install" script in each AppDir could interface with a package manager tool to fetch dependencies APT style.

No. In the system that we would like to build, there should not be, and developers would not be encouraged to release anything that require 100 libraries to work. Everything WILL HAVE to work. As in BeOS. As in OSX. As in Windows.
If the system has the required libs, that's fine. If not, the app should distribute its dependancies on its own package (this way, you can install a different version of the lib on your /usr/lib/ and still have that application running with your custom version, like in BeOS), or link to them statically. Dependancies are out of the question. They are the menace of the Linux/Unix today. Remember, we try to build a new system, a new OS. It just *happens* to be based on Linux. It might as well be based on FreeBSD! It doesn't matter! One thing is for sure, it won't be a yet-another-Linux-distro. It wouldn't even be binary compatible. It would be a new OS.

RE: okay
by Eugenia on Wed 29th Jan 2003 08:04 UTC

You got to be kidding.

Eugenia
by Andrew on Wed 29th Jan 2003 08:04 UTC

I have a quick question Eugenia.. whats with your obsession with Joe User?

Does *everything* have to be designed for Joe User? Would we, as a whole, benefit if everything was so completely and utterly dumbed down? Instead of comparing things like the Gnome Menu editting system to OSX's why not a fresh idea? If you like that system so much, it wouldn't be difficult for you to d/l the code and implement it yourself.. and by yourself.. I mean you're gonna be the only one using it since the current system is fine for me, and my Joe User dad.

RE: RE: Linux Desktop OS
by Omer Hickman on Wed 29th Jan 2003 08:06 UTC

>But by doing all that, does NOT MEAN that you break source compatibility. You might indeed break a few things here and there, but overall, porting a GTK+, X or Qt app to the new system should be TRIVIAL.

Existing distro like to break compatability already . . .
I mean subtle differences can make it a real gamble trying to use an RPM compiled on a different distro or even an earlier version of the distro your using.

RE: Eugenia
by Eugenia on Wed 29th Jan 2003 08:09 UTC

> whats with your obsession with Joe User?

It is not my obsession. It is my job. I used to be working as an interface designer in UK.

> Does *everything* have to be designed for Joe User?

Of course. The fact that YOU can go around badly designed UIs, doesn't make the specific UI design any better. It is still shit. It just happens that YOU know how to go around it. But it doesn't make it better. I am tryign to MAKE it better.

> Would we, as a whole, benefit if everything was so completely and utterly dumbed down?

Yes. See above. And it won't be "dumbed down". It would be more intuitive, even for you.

> Instead of comparing things like the Gnome Menu editting system to OSX's why not a fresh idea?

I already have. Read my previous message regarding the app launcher.

> If you like that system so much, it wouldn't be difficult for you to d/l the code and implement it yourself..

While I am a programmer, I don't have the incentive to go hacking code. I don't do it nowdays. My main job was web developer and UI interface designer. That's what I do best. And this is what I offer over here. Solutions.

Someone else will have to do the coding I am afraid.

> and by yourself.. I mean you're gonna be the only one using it since the current system is fine for me, and my Joe User dad.

Haha, you assume too much.

RE: RE: Eugenia
by Andrew on Wed 29th Jan 2003 08:15 UTC

>> whats with your obsession with Joe User?

>It is not my obsession. It is my job. I used to be working as an interface designer in UK.

You didn't get fired did you?

I see Eugenia
by Omer Hickman on Wed 29th Jan 2003 08:15 UTC

What you mean is that "FoobarOS based on Linux" has the libraries it ships with and developers should be expected to compile against the specific versions rather then the latest and greatest version of each library. That could work as a sort of "stabalized" linux. Developers and the existing Linux community can continue to do things in the chaotic bleding edge way as always but their progress could then be "backported" to this more stable Linux based platform.

RE: RE: Eugenia
by Eugenia on Wed 29th Jan 2003 08:19 UTC

>You didn't get fired did you?

Why this hostility Andrew? Why? I have worked my ass on usability with both the KDE and Gnome developers the last few months, and even the Synaptic guy, and I even worked on another OS project about UIs which I can't mention because I am bound by an NDA. So, I DO something for your beloved OS. I recommend ways to make it BETTER. But you, are just hostile! You are really low on my eyes right now.

To answer your question, no, I was never fired on any of my jobs in my life.

I stopped working in UK, because I got married and moved to USA. Happy now?

RE: I see Eugenia
by Eugenia on Wed 29th Jan 2003 08:23 UTC

Yes, you are now starting to getting it.

And remember: If a developer really needs to ship his app with the latest and greatest libs, he STILL can as I explained earlier, *without* breaking the system!
On BeOS, you just create a library folder in the folder where the binary lives, and the OS will FIRST try to load the libs found there for the given launched binary and if the OS won't find them there, ONLY then it will load the system library one!
So, when I used to port SDL games on BeOS, the <my game folder>/lib/libpng.so was a newer version than the one shipping with BeOS, and it would work with the binary I was releasing on the <my game folder>/mybinary, without breaking the OS!

RE: RE: I see Eugenia
by Omer Hickman on Wed 29th Jan 2003 08:49 UTC

This BeOS style of library overriding can be done now in Linux, possibly using the AppRun script in an AppDir, by loading the LD_LIBRARY_PATH with your app's library directory. In fact the script could probe the machine type so that the same package could contain binary + libs for multiple architectures.

RE: RE: I see Eugenia
by Eugenia on Wed 29th Jan 2003 08:56 UTC

Yes, but you are talking about scripts. I am talking about architecture here. I am talking about things that would work out of the box, as you expect them to, and not when and if a user runs weird scripts and load library paths manually.
The solution you offer is no better than the FreeDesktop one: It is a hack to ease the pain of the 30 years of Unix legacy.
This is not the way to go to the desktop. Unix was never designed for the desktop, it is a server architecture. To make Unix user-friendly, you will _have_ to throw away some of the legacy and certainly hacks like scripts and .desktop files are not the answer. Neither that terrible thing called "configure" which is also a script to figure out things for you, but it has end up to be a bloated piece of sh*t in which there is no way you can edit it by hand (scripts are supposed to be editing-friendly).

The Linux experience needs not only evolution at this point, needs revolution as well. I will bow to the one who's got the guts to do what Apple did with BSD.

libs and dependancies
by Nathan O. on Wed 29th Jan 2003 08:56 UTC

I think one of the differences between Linux and commerical OS's is that in Linux, most people just hand out the binaries from their home server, or from something like rpmfind.com. That's cool, cuz it's all free, but at the same time, it's harder that way to find dependancies. In a Windows app, all the dependancies are (usually) included on the nice CD you bought. I'm sure that if Linux apps more commonly came in boxes, people would tend to be better about dependancies.

However, since I likes me my free software, I think we'll stick with the idea of downloading everything for free ;) . I think we're talking about a new Linux, and not a new distro, correct? Of course it's correct. It's a lot like the difference between FreeBSD and NetBSD, I think. Maybe a little more stark. Basing it on Linux, I think, is a good idea, simply because of the hardware support.

There are probably 3 main things that need to change- the UI, dependancy hell, and packaging.

UI needs to be intuitive, of course. Features are great, but one of the reasons I don't use KDE is because I want my desktop to work for me- I don't wanna spend all day learning the ins and outs of all the features that my DE offers, and how it interacts with my GUI server when something breaks and I need to fix it. I want it simple. I use IceWM. Not horribly many features, but it stays out of my way while offering decent power. Of course, there's a lot of room for improvement over my favorite WM.

Packaging is a toughy. I hate RPM. I decided a while back that I'd exclusively use RPM to install anything, in order to keep things simple. Needless to say, I've abandoned that idea. Packages and dependancy hell are, needless to say, a nightmare! I have a lot of great ideas for packaging solutions that would eliminate dependancy hell once and for all for Linux, but of course these ideas would only work if developers flocked to it in droves. I'm sure all who read this could come up with similar solutions given even 20 seconds to formulate the entire system.

RE: RE: I see Eugenia
by Nathan O. on Wed 29th Jan 2003 09:05 UTC

"Unix was never designed for the desktop, it is a server architecture. To make Unix user-friendly, you will _have_ to throw away some of the legacy and certainly hacks like scripts and .desktop files are not the answer."

Absolutely!!!!

And what's wrong with making an intuitive desktop that can also be a power-user system as well? I think a lot of people don't realize, it *can* be done. I've only used MacOS X a couple of times, so I'm no expert, but I hear that underneith its beautiful exterior (which can be used by Joe User with relative ease) lies a UNIX system. One day, I walked in to my school's computer lab, sat down at a Mac, poked around, and within 1 minute was using a shell prompt!

I think that if power users would relax and open their minds to it, they'd realize that a well plotted UI can be good for productivity. To anyone who questions this, I ask: what do you use your computer for?

Computers are for computing. I use mine for 2 main things: poking around and learning about computers, and getting stuff done. A good UI is what Linux needs. I don't need more fluff. I don't need more features. I need a UI that helps me get more done faster.

Oh bother
by Richard K. Yamauchi, Jr. on Wed 29th Jan 2003 09:11 UTC

It seems like OSX will be copied and is accepted by both sides.

I don't want to have /usr/bin/programdir2:/usr/bin/programdir2
or even /usr/bin/Multimedia:/usr/bin/web/:ad infinum

I understand that /usr/bin is confusing for a newbie, or anybody for that matter with so many binaries. Perhaps the path could be /usr/bin/* which may or may not search all the directories. HOWEVER:::::

Sometimes breaking compatibility will break more than you bargain for. If you change this directory structure, it will be popular for a very small segment. It would end up dying because it would be so much trouble to work with.

Not that it was a bad idea, Eugenia, but it's just not feasable. The old way is too entrenched. It also has it's reason for being.

However, I have no problem with a $HOME/Multimedia:$HOME/Web:$HOME/Graphics ad infinum that link to /usr/bin (which I guess is what OSX has, or close to it). You get the best of both worlds. The Gui will show the $Home organization, while the /usr/bin structure stays for CLI and other compatibility (aka as ooops, that's why it was like that).

Anyways Joe User should not be looking in /usr/bin (Should as in most likely will not, not bad Joe user, go to your room. Think about what you just did Kids today are so disrespectful). On the other hand, I tried putting applications:// in the address bar in nautilus and got "applications: is not a valid location. (I'm using XFCE, not Gnome if that matters. I'll try it in Gnome later). BUT, according to the Gnome guide in nautilus under help, there is Drag and Drop. I'm so confused, I'll stick to satire.

RE: libs and dependancies
by Eugenia on Wed 29th Jan 2003 09:12 UTC

>There are probably 3 main things that need to change- the UI, dependancy hell, and packaging.

Hmm, actually, there are more.
The fact that the LD loader doesn't like C++ is a big minus and needs fixing ASAP. Problem is that there are not many hackers working on this, neither has a hard clue how to fix it, as it is a hard problem. So, this is one that really needs to be fixed.

Then, it is the whole issue of NOT breaking binary compatibility on each Linux kernel version for the drivers. This is _unacceptable_ for companies who write closed source drivers for your system. So, you will need to modify the Linux kernel to make sure that it can easily install new drivers, unload others, and keep compatibility for many years to come. That means, that you _might_ have to fork the Linux kernel (however that would be a very "soft" forking, as you would still send back your fixes to the main kernel tree, and you would still populate yours with their new stuff).
Adding a few good file system additions, changing the policy for the drivers etc etc, changing the loader, optimizing or even usign the freebsd glibc instead of this terrible GNU glibc, will make you lose binary compatibility with the rest of the distros, and it will require you maintain large and DIFFICULT chunks of code, all by your team. Remember: This is so tough because we are talking on creating a new OS, a new platform. Not yet another distro where we are throwing stuff in it.

And then, you will need to optimize and change X to be user friendly and then do the UI and stuff. And you will also need to take care the filesystem (I would recommend XFS with full attribute support and live queries as in BeOS). And you will need to work on different parts of the fs hieriarchy as well...

As you can see, this is not trivial. It is not a "let's fix the obvious things that we don't like today". Remember: it has to be done right the FIRST time. Because if you do something wrong, a bad design decision in vesrion 1.0, and then you want to fix it in version 2.0 and that might change your architecture or break older applications, this would be a NO-GO, because user-oriented OSes, are known for being compatible for years. If we want to break compatibility with ourselves every 6 months, you better stay with your current Linux distro and forget this whole project.

Now, who's got the guts to do all that? ;-)

RE: Oh brother
by Eugenia on Wed 29th Jan 2003 09:16 UTC

>Sometimes breaking compatibility will break more than you bargain for.

You don't understand. /usr/bin HAS to stay there, otherwise you lose POSIX compatibility! Nobody said to erase the /usr/bin. But you DO hide it. System tools will be in the $PATH, while gui apps will be elsewhere. But the /usr/bin all its sister dirs will be there, because no matter what, POSIX compatibility SHOULD BE maintained AT ALL costs!

re:
by c on Wed 29th Jan 2003 09:17 UTC

>You got to be kidding.

I hesitate to comment again.

Please explain why you think I'm joking or how your method would differ and how it would integrate into UNIX. I cannot foresee a Linux without UNIX, except perhaps in the smallest embedded environments, but even PDAs keep most of the filesystem intact.

Perhaps you have stumbled upon some revolutionary new idea to organizing an OS. If so then maybe I just didn't understand what I read. Again, I appoligize for expressing my opinions.

Yikes
by Richard K. Yamauchi, Jr. on Wed 29th Jan 2003 09:20 UTC

Eugenia, you responded to my post faster than I could view it!!!

I personally would like to do more research. I guess I'm not seeing the full picture.

For me, all guis are pretty similar. Click. Click. Click. Type. Click. Click. Click. Drag. Click. Click.

I'm not sure the best way to do this. Where's the best place to look to see everybody's opinion on guis and DE's/WM's? (XP vs OSX vs KDE vs Gnome vs TVWM etc). Otherwise my only contribution to Linux will be telling people I can write funny stories about it.
Did I mention click?

RE: libs and dependancies
by Eugenia on Wed 29th Jan 2003 09:20 UTC

Oh, and you might need to create a new binary format, or maybe an ELF that supports more advanced stuff, like resources.
As you can see, this is real OS design here, we are not talking about a "distro". We are talking on creating a new modern OS. It just "happens" to be using the Linux kernel. You have to think of it this way, in order to understand how big of a job really is. And you need to decide how you lay out your /etc/ and if you want to be more unix compatible or more Linux compatible in your /etc/rc dirs etc etc. There are a lot of things to be brought back to the drawing board. Take nothing for granded. Everything can be changed if it is needed.

RE: Nathan O.
by Omer Hickman on Wed 29th Jan 2003 09:21 UTC

>I have a lot of great ideas for packaging solutions that would eliminate dependancy hell once and for all for Linux, but of course these ideas would only work if developers flocked to it in droves. I'm sure all who read this could come up with similar solutions given even 20 seconds to formulate the entire system.

**sigh** that is so true.

You hit the nail on the head on this point. I try to keep to only installing from APT-RPM or RPMs too but always find something that is only in a source tar ball that I must have ;)

@Eugenia:
I don't see the ROX approch as hackish. Most Linux programs I have compiled run from with in their source trees without a 'make install' so making existing programs live completely within their package directory is no big deal. As I understand it, this is exactly the way applications are done on OSX. Most ROX packages use a script to start them for the sake of first run setup or compile. Most programs that are targeting "FoobarOS" will be dependent on the default support libraries any way. I can see providing programmers with a "porting wizard" to "FoobarOS" that would automate any details of creating a Package including any initialization scripts and bundeled libraries.

RE: C
by Eugenia on Wed 29th Jan 2003 09:22 UTC

>Please explain why you think I'm joking or how your method would differ and how it would integrate into UNIX.

I think we have misunderstood each other. You are talking on integrating your script/hack into the *known* Unix OSes.

Me and a few others are talking about a new Unix-based OS, where these kinds of hacks/scripts won't be needed, because they would be taken care by the system by default, in the first place.

I think we just started talking on different things here and we start misunderstanding each other. Sorry about that. ;)

RE: Nathan O.
by Eugenia on Wed 29th Jan 2003 09:27 UTC

> I can see providing programmers with a "porting wizard" to "FoobarOS" that would automate any details of creating a Package including any initialization scripts and bundeled libraries.

Creating a new package for the FoobarOS, would be done via a wizard. It wouldn't be a command line utility. It ain't so neither in Windows, Mac or BeOS. And it doesn't have to be. A wizard/form kind of thing, like in OSX would be great. Stop thinking again with the Linux mindshare of "in order to create a package I go to the command line and I have to do this and this and make sure that this is already there".
As for porting the app itself, configure/make would STILL work in addition to GUI IDEs/tools. Remember, we are talking about a POSIX system still. It is important that any new OS, does remain POSIX.

Not this again?!?!
by Mike Hearn on Wed 29th Jan 2003 09:28 UTC

ARGH! AppFolders are NOT the way to do this!

OK, let's take this one step at a time.

1) Yes, Eugenia is right, using applications:/// to edit menus is a bit sucky, being able to edit the menus directly like in Windows would be better. On the other hand, editing stuff using the file manager is exactly what MacOS does, and I don't hear any bitching about that? How about if we removed the menu entirely and forced you to keep around a nautilus window, would that be better? I don't think so, but that's what MacOS does.


2) So anyway. The .desktop spec is fine. No, there's NO reason to make something XML just for the sake of it, if you actually read the specs you'll see that it's very extendable, and much easier to read/edit by hand than an XML based format would be. It gains simplicity and sacrifices.... what? You don't need to style or transform .desktop files

3) No end users should see the system directories at all. Sorry Eugenia, but dragging files from there into the menu is a dumb idea, the entries should appear in the menu when you install and disappear when you uninstall. If you want to remove them, just delete the entries. Why make the user perform extra actions?

4) Yes, splitting things out into separate files is fine. It lets you smoothly integrate applications from multiple locations into the same menu, with varying levels of administrator control. It lets you invoke a program from the command line, or the menu, or the new "smart" run dialog box. It lets you retheme application icons if you like, and generally makes the whole process more transparent. AppFolders have lots of disadvantages which I've gone into time and time again, and so far nobody has really convinced me otherwise.

@NathanO:
"I'm sure all who read this could come up with similar solutions given even 20 seconds to formulate the entire system."

Yes yes, I'm a pimp, come help us out will you? http://autopackage.org/

@Eugenia:
"The Linux experience needs not only evolution at this point, needs revolution as well. I will bow to the one who's got the guts to do what Apple did with BSD."

MacOS X is basically just NeXTStep with a facelift. Interesting a decade ago, but it's hardly revolutionary. Most of the big fuss in this particular thread seems to be over AppFolders which won't ever work on Linux and that has nothing to do with it being unix, or having lots of 'history', it's a social thing.

Anyway, I think you have an odd definition of "hack". The freedesktop.org standards aren't hacks, they are well thought out solutions to problems which often aren't obvious until you sit down and talk about them. When you write your RFCs, are you taking into account system admins on large networks? The need for partially sighted people to have high-contrast icons? Yes? No? I've said it before and I'll say it again, making things appear simple is fine, but losing important features because it is simple isn't fine.

Sleep
by Eugenia on Wed 29th Jan 2003 09:29 UTC

ok guys, I need to go and sleep. It is 1:30 AM here and tomorrow morning I need to go for my French lesson. It was a good discussion overall.
'Night.

SVG?
by Mike Hearn on Wed 29th Jan 2003 09:30 UTC

Oh, one last thing, does anybody else think that actually the stock gnome artwork is much prettier than these SVG themes? They seem kind of messy and lacking the subtle details that I love from the bitmap artwork.

I guess it's just that SVG themes are still in their infancy.

ahhh
by c on Wed 29th Jan 2003 09:32 UTC

Understood. What I don't understand is how it is easily modifiable from the command line. I personally don't like editting xml. I guess that's my only concern. Need to admin these things.

RE: Oh brother
by Nathan O. on Wed 29th Jan 2003 09:33 UTC

"You don't understand. /usr/bin HAS to stay there, otherwise you lose POSIX compatibility!"

Which goes back to what was said about a separate dir for app binaries.

Refresh my memory; what exactly is /opt for? Isn't it for programs? So why not have something like /opt/bin? Just a thought. Something to keep apps seperate from basic OS utilities. God forbid we put /opt to much use ;) .

Also, UNIX being made for the computers it originally was made for, I can understand having such a focus on multiple users. But how many of you honestly share your computer with several other people? Personally, there are three accounts on my computer- root, nko (my initials), and user (which I use to dink around in). Notice the lack of other people using my *Personal Computer*. Of course, I like the idea of multiple users, and I like that it's supported much better and in a much more meaningful way than in Windows, but I think some emphasis could stand to be taken off of it since we're talking about a desktop Linux. Not take it away, not dumb it down, just not focus on it so much. For example, if Phoenix is open and I click its icon again in GNOME, it tries to ask me which user wants to open it. K, bad example, but I hope I got my point across. It's a light difference I would like to see ;) .

RE: Not this again?!?!
by Eugenia on Wed 29th Jan 2003 09:37 UTC

> On the other hand, editing stuff using the file manager is exactly what MacOS does, and I don't hear any bitching about that?

Yes, and I find it wrong. Especially the fact that ALL the apps are in the /Applications directory which is a big stupidity. I have often said that OSX has problems. This IS one of them.
When I was talking about DnD, I was mostly reffering to the Dock.

>You don't need to style or transform .desktop files

It is much better to be XML, because you can much easier write an app that can parse these files and create a UI for you to manipulaet these values.

>No end users should see the system directories at all.

But... I agree on that!

>Sorry Eugenia, but dragging files from there into the menu is a dumb idea

What are you talking about? Have you READ what I wrote???
I never said that is acceptable to dnd from /usr/bin/.

> Yes, splitting things out into separate files is fine. It lets you smoothly integrate applications from multiple locations into the same menu, with varying levels of administrator control.

Right. And can you please tell me where this is useful on a USER system? I think that feature is completely useless. Why would I want my icon for my binary to live in a server in Alaska and the binary to live on my box?

> It lets you invoke a program from the command line, or the menu, or the new "smart" run dialog box. It lets you retheme application icons if you like, and generally makes the whole process more transparent. AppFolders have lots of disadvantages which I've gone into time and time again, and so far nobody has really convinced me otherwise.

The system I would like to use does NOT hold you back from ANY of these issues. Have you ever used BeOS? I think not.

Goodnight.

AppFolders
by Nathan O. on Wed 29th Jan 2003 09:48 UTC

Oi, I think we're all in agreement here. Requiring the user to open a folder of any kind just to launch a program is pretty innane. Might as well be running every program from an xterm.

G'night, Eugenia!

RE: Not this again?!?!
by Mike Hearn on Wed 29th Jan 2003 09:49 UTC

"When I was talking about DnD, I was mostly reffering to the Dock."

Oh, ok. I think you can drag menu entries from the menu onto the panel, maybe there is a bug on that, not sure.

"It is much better to be XML, because you can much easier write an app that can parse these files and create a UI for you to manipulaet these values."

Not really. Writing parsers is a programmers bread and butter, they aren't difficult. I don't see how using XML would make it easier to write a GUI for it, afaik there is no generic XML->GTK/Qt binding framework, and anyway specific guis are better than generic ones in this case.

"What are you talking about? Have you READ what I wrote???
I never said that is acceptable to dnd from /usr/bin/. "

Meh? I'm confused! I thought you said:

"This is one of the reasons why drag-n-drop wouldn't work directly from /usr/bin/ to your Gnome menu and automatically get its icon and everything. These are the times I say that the whole Linux experience needs to be re-thought"

.. and ... "And I am not talking about drag it to the app folder. I am talking about dragging it to the menu directly."

You mean, dragging a package directly into the menu? If so then we've considered this, it's certainly possible to do, regardless of the underyling structure.

Anyway, filing systems will be databases soon anyway ;) So, what, are we going to let the users browse the data structures from Nautilus? No... better to let them forget about how the underlying structure is organized.

"Right. And can you please tell me where this is useful on a USER system? I think that feature is completely useless."

The user need never know it even exists! Once we have the various bugs and packaging problems ironed out, it will Just Work (tm) and that feature will be there for when admins need it, and the rest of the time users won't need to care.

"Why would I want my icon for my binary to live in a server in Alaska and the binary to live on my box? "

It's more a case of, what if you want different icons for the binary, like high-contrast/low-contrast icons? Or you have a nice big icon theme. Or you want to store icons in multiple formats etc.

"The system I would like to use does NOT hold you back from ANY of these issues. Have you ever used BeOS? I think not. "

(sigh) No, I have not. I did try, but the download constantly corrupted. I've yet to find an explanation of exactly how BeOS managed menus and packages and stuff. I'd guess using an AppFolders style system. I'll have a look for such an explanation, but if you have any urls or screenies that'd be good...

"Goodnight."

Sleep well ;)

XML
by Nathan O. on Wed 29th Jan 2003 09:52 UTC

Come to think of it, if all the settings that the user should be able to manipulate were in XML files, we could easily have two great ways to edit preferences and settings: by hand in a text editor, or in some universal program that pretty much just loads an XML file as a table... sort of thing. To change an attribute, just find it and change its value. XML is really useful for stuff like that, and a program that could load any of this new GNU/Linux system's XML settings files would be relatively easy to make. Just impliment a parser and have it spit out options and values in a nice, clean interface. Another of my "just a thought" posts.

re: XML
by Nathan O. on Wed 29th Jan 2003 09:55 UTC

Or, I guess that idea basically just got shared before I posted it! :-D

RE: Not this again?!?!
by Eugenia on Wed 29th Jan 2003 09:57 UTC

> I thought you said:

"This is one of the reasons why drag-n-drop wouldn't work directly from /usr/bin/ to your Gnome menu and automtically get its icon and everything.


That was in the beginning of our discussion here, and the highlight in the sentence is about the dnd and the icons, not the /usr/bin/ in particular. I could have used /bin/ there as the example. The /usr/bin/ in that sentence was just the context so people would understand what I was saying about Dnd and icons. Later, I CLEARLY explained about how gui apps should not be stored there.

>You mean, dragging a package directly into the menu?

Possible yes. But it won't get its icon automatically. Are you talking about packages though, or apps?

> It's more a case of, what if you want different icons for the binary, like high-contrast/low-contrast icons? Or you have a nice big icon theme. Or you want to store icons in multiple formats etc.

No, none of these reasons is good enough to make me wanna have a .desktop file, lying on my ~home and getting itself broken when the admin deletes the binary.
Different icons can be changed by editing the resources or the package. BeOS did it the best way. It is really easy to do so.

> [BeOS] I'd guess using an AppFolders style system.

Nope. Bad guess. Re-download Max Edition from BeBits please. ;)

And now _really_ I have to go to sleep.

best comment all night....
by shifted on Wed 29th Jan 2003 10:09 UTC

3) No end users should see the system directories at all. Sorry Eugenia, but dragging files from there into the menu is a dumb idea, the entries should appear in the menu when you install and disappear when you uninstall. If you want to remove them, just delete the entries. Why make the user perform extra actions?

Is there *any* need for things to be more complicated than this? I should be able to drag an icon from a web-browser or from a cdrom, or wherever, to my menu/dock/etc and have it install. When I delete that icon from the menu/dock/etc, the program uninstalls. Library dependencies are fine, if done correctly (e.g. debian).

just a correction...
by ph on Wed 29th Jan 2003 10:15 UTC

Yes, Eugenia is right, using applications:/// to edit menus is a bit sucky,

You are not supposed to write "applications:///" on nautilus to edit your menu. You are supposed to go to "Start Here" on your desktop, and then to "applications". It's not as fast as doing it in the menu directly, but works quite well.

3) No end users should see the system directories at all. Sorry Eugenia, but dragging files from there into the menu is a dumb idea, the entries should appear in the menu when you install and disappear when you uninstall. If you want to remove them, just delete the entries. Why make the user perform extra actions?

I agree. It's the way it should be. Most of the problem lies on the installation of new apps.
Apps can be easily installed with installer like the one found on loki games. They just make you click a couple of times, and then they create a menu entry for KDE and Gnome.
If they need to use they own libraries, the just create a /opt/fooapp/lib that will be used for the program library. Then a symlink from /opt/fooapp/bin is created to /usr/bin.

Users dont even need to know that a /usr/bin directory exists. They just need to worry about the installation program.

re: just a correction...
by Nathan O. on Wed 29th Jan 2003 10:21 UTC

"Apps can be easily installed with installer like the one found on loki games...."

Exactly! That's how easy it should be, and it should work like that, creating its own set of libs that it ships with.

RE: Linux Desktop OS
by Arto on Wed 29th Jan 2003 10:37 UTC

I may have exaggerated a bit in my examples, but I really did not misunderstand.

What I meant is this: if you have a nice wonderful Linux Desktop OS, as you envisioned, you won't be compiling things for it. People get, and need to get, ready, easily installable packages (binaries).

And those binaries won't run or install on Linux... on real Linux, you'd grap the sources and compile, fine, no problem.

But to get those ready packages for the desktopux, you need someone to make them. Are the developers of all the famous and most productive free/open source software ready to jump ships from their good ole tarballs and just start supporting the new way.

Well, if they aren't, you are going to need a third party to keep the whole thing going. The same role as the distros are doing these days. And it'll come to be a brand new mess.

The fact is that Linux is too open source, open everything. It is very fragmented, and I have a hard time envisioning anything central, and heavily supported + used, controlling all this, and doing it in free+open source tradition (which would, more or less, be the whole point of having Linux on desktop; you didn't answer why otherwise something like that should be needed?).

But anyway, what do I care, I wouldn't be using anything like that, as I don't use Linux even now.

UNIX design?
by Arto on Wed 29th Jan 2003 10:47 UTC

I am sure that you know, Eugenia, who and in what situation designed and created UNIX.

From that knowledge, it is true that UNIX was never designed for desktop, but "it is a server architecture" is a bit of a stretch, if we are talking about the design of UNIX.

UNIX was mostly an ad-hoc creation, 30 years ago, to serve as a multi*user* operating system . And UNIX was the thing people did run on their "desktops" of the time. Of course "desktop" then was just the commandline at a terminal, but really, the people who used it were Joe or Mary Users, writing documents and so on.

And what is it in UNIX design that makes it a server, not a desktop capable?

And besides, I have the feeling that all one would need to do is: make the GUI work. Make it really work. This does not require changes in the kernel, or the standard file hierarchy. Changes can, and perhaps should be, introduced to the file organization, it is not such a big deal. But, you can hide it all with the GUI.

What I mean is: you gave an example about the Mac OS X packaging system, and how the things are integrated in the package (you spoke about file deletion, and so on). What I want to know: if you go to terminal, and start mucking around with files that belong to some application package, does everything work as nicely as if you were in Finder.
(My guess: no. Therefore: the complexities are hidden in the GUI, the OS doesn't really care.)

Sounds like a separate article.
by OoSync on Wed 29th Jan 2003 12:06 UTC

Eugenia, might I suggest you write up your thoughts as an entirely separate article. This would give a clear and concise method to distribute them to all of the *NIX UI developers (hey, *BSD and kin use the same GUI systems and similar file hierachies and structures). Also, I would suggest you only write this document in terms of features you wish to have: "DnD binaries to menus, automatic selection of icons, ability to *transparently* run applications from their own folders, etc." My basic suggestion is to focus on describing and evangelizing the features you desire and not the underlying means of implimentation. For the end user you are describing, such implimentation details are grossly unimportant as long as the UI does what he or she expects consistently. Personally, I don't think so many radical changes are necessary, but that's implimentation, let the coders and hackers figure it out, just let us do the things we want in peace.

AppFolders using RPM
by OoSync on Wed 29th Jan 2003 12:27 UTC

As an implimentation detail, I agree that the BeOS way sounds really useful, i.e. looking first for libraries in the vicinity of the binary, then using system libraries. Automated, I know of at least one application this for which this will not work (Intel C++ and Fortran compilers) because their directories are not <app>/bin, <app>/lib, but they are exceptions. As stated several times, this can be "faked" using runme.sh style scripts to setup binary and library paths and then run the application. At the moment, i.e. lacking mor e transparent implimentations, this is the easiest way to simulate AppFolders. I think this can be made even easier as a switch in rpm or deb (or other package) based systems. A command line switch (can be set on by default in a distro) will trigger the rpm to change the install directory from "/" to "/opt/<app>" or somesuch. Next, for each binary present in "/opt/<app>/bin" the rpm command can then *transparently* create the runme.sh scripts. I would also suggest (implimentation detail) that each script is given the full version numbering of its package, and that a symlink is created by rpm to (1) first such script installed, leaving other user callable, or (2) the latest in the case of package upgrades, or (3) to the version specified by the package author. Users can alter this decision without any additions to rpm by removing the symlink and using their own. Sound reasonable?

117 messages and counting...
by Cesar Cardoso on Wed 29th Jan 2003 13:05 UTC

Oh, let's try a bit ;)

Eugenia: These are the times I say that the whole Linux experience
needs to be re-thought and even break multiple compatibilities with
older crap, just to retool things to work as they suppose to work on an
OS that wants to get to the desktop (as Linus said yesterday) in the
year 2003.


GNOME (KDE also) runs on multiple OSes. If you break things in Linux,
you'll probably have to break things in Solaris, Free/Net/OpenBSD
(although I wonder if anyone uses OpenBSD as a GNOME/KDE desktop :-) etc
etc etc.

bsdrocks: Nope, no change in 2.2.. I think, it's going to be in 2.3
or so. I don't see anything wrong with file dialogs, thought. ;-)


GNOME/GTK file dialogs simply sucks real big time. Ximian ones are
better, but not that much. Every GTK/GNOME developer knows that, but
unfortunately no clear winner has arrived.

dealing_death: Noone needs a PATH for GUI apps.

That's why people invented applications menus, start buttons and so on,
right? :-)

Mike Hearn: I guess it's just that SVG themes are still in their infancy.

SVG is something really new, it'll be a

Nathan O.: Might as well be running every program from an xterm.

...because sometimes fire an xterm and type a name is sooo faster than
opening a menu, opening another menu etc ;)

v Uhh
by Aitvo on Wed 29th Jan 2003 13:18 UTC
RE: Not this again
by Mike Hearn on Wed 29th Jan 2003 13:59 UTC

"The /usr/bin/ in that sentence was just the context so people would understand what I was saying about Dnd and icons."

OK, so you want icons to be included as part of the binary. Fine, but that removes flexibility for..... for what? I still don't understand how having the icons separate from the binary is a hack.

"Possible yes. But it won't get its icon automatically. Are you talking about packages though, or apps? "

To me they are one and the same. I meant if you find a package file, to install it you just drag it to the Apps menu and drop. It'd categorise itself automatically. If you wanted to override that category, you could drag it to some other folder (or the applications:// folder). One idea I had was to create a new XML namespace for plugging into XDND, and then a Gecko plugin for it, so app developers could "embed" the package into their web page. The package would obviously have the icon of the application. Users just visit the webpage and drag the package out of the page onto their menu, or the panel, or whatever they use to launch apps. The package is then downloaded and installed transparently via the resolver network.

I guess if you wanted you could drag it into a file browser and have it just act as a normal download too, but I think this would be a very easy way to manage software - google for it, drag on, drag off.

Once all the links to the app in the menu/panel for all users have gone, the package can be uninstalled automatically by a cron job or something, so users don't have to worry about explicitly uninstalling packages, they just remove the links to them from their desktop.

"No, none of these reasons is good enough to make me wanna have a .desktop file, lying on my ~home and getting itself broken when the admin deletes the binary. "

Admins shouldn't and don't just delete binaries. For starters, doing it manually leaves the shared data and libs lying around. No admin I know uninstalls software manually, they either use the package manager or "make uninstall". Bear in mind the .desktop files are completely hidden from the user, they need never know about them.

" Different icons can be changed by editing the resources or the package. BeOS did it the best way. It is really easy to do so. "

Ack! Sounds hard if you want to do them in bulk. You'd have to track down every binary and do edits inside them. That's hard, and asking for file corruption.

"Nope. Bad guess. Re-download Max Edition from BeBits please. ;) "

Aw suck. Maybe if it runs in VMWare, I've completely run out of space on my own machine.

@Shifted: Yes, I thought of the same thing about a month ago. It's most certainly possible, but it needs some careful thought and good integration. Obviously you'd need to patch the rendering engines too. In fact we can make it more generic, so it's not just packages that can be dragged off of web pages, but any files/objects. You can already do this with images afaik.

@NathanO: "Exactly! That's how easy it should be, and it should work like that, creating its own set of libs that it ships with."

Not that easy I'm afraid, you can't ship the entirety of gnome2 around with every gnome app ;)

@OoSync: "A command line switch (can be set on by default in a distro) will trigger the rpm to change the install directory from "/" to "/opt/<app>" or somesuch. Next, for each binary present in "/opt/<app>/bin" the rpm command can then *transparently* create the runme.sh scripts."

Unfortunately many Linux packages aren't relocateable, they must be installed to the same location they were built for. We're trying to solve that by convincing people to link against libprefixdb, which allows apps to locate their datafiles from the package database at runtime, but this is a bit hacky. It's fine for now, but for the long term I think a better solution is to move to a system more like Windows, where apps have their shared data/libs in the same directory. The mods needed would be small, but the old way has advantages too that you'd lose. So I'm not really sure if that'll happen.

"Users can alter this decision without any additions to rpm by removing the symlink and using their own. Sound reasonable?"

Yes, that's basically what autopackage does ;) If there is already a binary with that name in the path (for home user installs, not sure if we currently do it for global installs as well) then we setup symlinks that will take precedance. I don't think we do this for global installs actually, fiddling the path gets complex. For non-root installs though we do this.

What is /opt for...
by Peder on Wed 29th Jan 2003 14:11 UTC

I personally install all my self-compiled programs in
/opt/<program-name-and-version> and use the excellent 'stow' command (btw does anyone know of any distro that installs it by default??) to make symbolic links to /usr/local. This way I only need to add /usr/local/bin to my PATH and /usr/local/lib to ld.so.conf.
It also enables me to have multiple versions of the same program installed (for trying a new version for instance); just unstow the old and stow the new. If the new version buggs or is crappy, unstow, rm -r <new-version>, stow <old-version>.

Just intergrate it into Gnome KDE
by Richard James on Wed 29th Jan 2003 14:17 UTC

Just make an app installer that when you click on a package it installs it the way you said. You can write a script and hide it you don't need to rewrite anything but the top level interface for executing an install.

OSX hides it
Windows hides it
Linux can hide it

its called automation.

If you want to change it that much then it won't be linux anymore because it really won't be compatible. The new distro would have to compete. If you made it into KDE and gnome all distros could benefit

BeOS
by Mike Hearn on Wed 29th Jan 2003 14:18 UTC

Hmm, seems to use a centralised package manager, something similar to RPM? Software Valet, then you choose where you want to install it, no fixed location etc. Icons are compiled into the binary like in Windows.

Alittle off-topic...
by Nick Slaughter on Wed 29th Jan 2003 14:54 UTC

Just got Gnome 2.2 RC2 installed and what can I say... I absolutely love it. For all Gentoo people there are ebuilds in the forums (Final will be in Portage though).

Don't know if it's the new version or because I changed compiler flags since RC1 but damn, this thing is flying, especially Metacity, resizing opaque windows is close to BeOS performance... me likey.

Give this release a go if you're a Gnome, and report any bugs you encounter so we can make sure Final is the best product possible.

eugenia you will never be happy with gnome/linux
by smoke on Wed 29th Jan 2003 14:57 UTC

until it looks like and acts like either osX or windowsXP. anyway - i think i stop reading osnews. its just too well ... nevermind.

Another menu comment
by Daan on Wed 29th Jan 2003 15:05 UTC

Just another comment on the Menu Editing from me:

KDE has a menu editor, not such a good idea. However, the AppFinder presents a list of all found apps, you can mark all that you want to add to the menu (by default only apps like Gimp are marked) and after OK everything is done.

all this garbage about menus...
by AdamW on Wed 29th Jan 2003 15:08 UTC

There's a perfectly good solution to all this crap about files and menus...

packaging.

I run Mandrake. Mandrake packages a close approximation of all the Linux applications under the sun, and when you install one that you're likely to run from the GNOME or KDE menus...it gets a menu entry. Your end-luser doesn't need to *know* where the binary is. They install the program and hey, there it is on the menu. No fuss, no mess.

follow-up...
by AdamW on Wed 29th Jan 2003 15:13 UTC

To clarify...have you seen how the average luser uses Windows? Have you seen one actually *add* an entry to the start menu? Hell no. They let the installer do it for them. There's no reason Linux shouldn't work the same way.

re: john g
by jerkasaurus on Wed 29th Jan 2003 15:31 UTC

Quote:
The most sensible way to do it is very close to the way MS does it.
You need a directory called ~/gnome_menu (or somesuch). In that are
subdirectories: Extras, System_Tools, System_Settings, Games, etc...
One for each label you want to show up in the menu.

Using nautilus, right click and drag apps from /usr/bin (or wherever)
and drop them into these folders choosing to create symlinks. Bang.
They should then show up in the menus.

And *that*, my friends, is the way it should work.

Response:

The great thing about computers is that there are multiple ways of doing things. However, whether you are accessing a program from a menu, or from a file browser, it should be just as intuitive either way, and you shouldn't have to relearn anything to do one way or the other. Here is the solution:

As Eugenia hinted, the "way it should work" is that the *nix desktop idea needs to be re-evaluated. 1) store all user applications in one "applications" folder. 2) Make a symlink from the well-organized applications folder to the menu.

Now the user follows the same path (e.x. , Internet, Mozilla) no matter if the applications are accessed from a menu or from the file browser (e.x. nautilus). The user still knows that Mozilla is in the applications directory under internet.

Note that I've replaced applications with menu, as it is more intuitive (and quicker!) to have a two-level menu than a three-level one.

This is the most logical, intuitive way I can think of to do this. Of course, it's probably the hardest to impliment because you might break compatibility, or at the very least you would have to abstract the unix filesystem (/usr, /bin, /etc...) from the user.

Re:
by Strike on Wed 29th Jan 2003 15:41 UTC

As Eugenia hinted, the "way it should work" is that the *nix desktop idea needs to be re-evaluated. 1) store all user applications in one "applications" folder. 2) Make a symlink from the well-organized applications folder to the menu.

[ddipaolo@quinn ~]# ls /usr/share/applications
archive-generator.desktop gnome-sound-recorder.desktop
drwright.desktop gnome-stones.desktop
eog.desktop gnome-system-log.desktop
file-roller.desktop gnome-system-monitor.desktop
--snip--

Like that? And menus are generated according to the contents of these .desktop files. So, what you are asking for has been done already.

OS Idea
by Daan on Wed 29th Jan 2003 15:56 UTC

In the summer, it happened that I thought about a new directory structure for Linux too... It is possible to implement it as a new *distro*, I think.

1) All system tools are in /usr/bin and/usr/sbin.
2) There are fixed versions of the default libraries. /usr/lib/glibc.so.2 always points to a certain version.
3) You have a /opt directory. /opt/<your-PC> for local programs, but you can also add /opt/tex-server and /opt/app-server and so on. IT IS VERY IMPORTANT that this folder is called the same on EVERY PC in the network! An app might be compiled to store its config in /opt/app-server/tex/fonts.list, hardcoded!
4) In each of these servers, there is /bin. Contains just symlinks to the programs. Only place user programs here.
5) Programs live in /opt/server/app/bin. App-depend libraries in /opt/server/app/lib and so on. If the app needs to install a certain library, it is allowed to install it. Say it needs glibc-2.2.2-22, it can install it in /opt/server/lib. In this manner, if two programs use the same non-standard library, it only needs to be installed once. Call this file indeed glibc.so.2.2.2-22, so different versions do not conflict.
6) A conjob might look for changes in /opt/*/bin and add all files to /opt/bin.

Compiled programs will in this way be hard-coded with a certain server. This might be solved by using an environment variabele, set when you start the program. Maybe it is possible to write a helper utility, say /usr/bin/start, that looks up on which server the program is, sets $SERVER to it, then runs the program.

If this works:
1) You can install apps very easily
2) Joe User can find apps easily, he just needs to look in /opt/bin for it, because this dir only has the user apps. System apps are in /usr/bin.
3) The system still supports running apps via network, just like a NFS-mounted /usr. Additionally, in this way it is possible to use apps from different servers at the same time.

It is not POSIX, but should work, as almost all programs have ./configure --prefix= To make it POSIX it is allways possible to use links...

paths
by Anonymous on Wed 29th Jan 2003 16:21 UTC

/System/
/User/

What more is it to it?

Forget about opt,usr,etc,proc,var,local,lib,dev,tmp,sbin,boot,sbin and what have you. It's all shit!

And that crap about following posix standards? Bah! Linux might just aswell follow the danish toilet standard.

RE: paths
by Daan on Wed 29th Jan 2003 16:32 UTC

> What more is it to it?

Well, the ability to mount applications remote. In this way the "desktop Linux" is also suitable for companies etc.

Re: Eugenia (Unix filesystem mess)
by Hongli on Wed 29th Jan 2003 16:45 UTC

Ah, a war between the pro-2000-files-in-/usr/bin and the pro-every-app-it-its-own-folder people. Ho! Wait! Stop!

Eugenia, you said you don't want to search for photoshop in a dir with 2000 files. I understand that, but ask yourself this: WHY would you want to search for the binary anyway? The best way to launch Photoshop is to use the menus. Browsing to C:Program FilesAdobePhotoshop is *not* userfriendly.

/usr/bin is a mess. That's great. But why are you bothered by this? Desktop applications should be started using a menu, *not* by browsing to /usr/bin. Creating shortcuts on your desktop/panel involves dragging the menu item to the desktop/panel, *not* by browsing to /usr/bin.

Why should the user care about the app's internals? Why should he know where it is installed? It works, and you launch it by using the menus, *that's* what matters. Why do you want to install every app to it's own directory if all you're supposed to be interacting with is the menus/icons anyway?

RE: Paths
by Mike Hearn on Wed 29th Jan 2003 16:56 UTC

And that crap about following posix standards? Bah! Linux might just aswell follow the danish toilet standard.

You do realise that there are significant problems with Apple doing it this way? What if you don't speak English? /etc may not mean much to you, but /System/Library will mean just as little, and if you understand English but want it in your own language, it'll just piss you off.

How I'd do it
by Kasper on Wed 29th Jan 2003 17:22 UTC

IANAUID (I am not a UI designer), but here goes nothing.

I think a lot of things could be done on a filesystem level if you used a filesystem that enables metadata for all files. An installer (be it GUI-based or something like emerge or apt-get) should put files the same places it puts them now, but add metadata to the executable, libraries and data files. I imagine something along the line of this:

/usr/X11R6/bin/pr0nview (executeable) has the following metadata:
Application == pr0nview
FriendlyName == pr0nview (Image viewer)
Version == 0.1.0

/usr/share/pr0nview/* (application data) has the following metadata:
Application == pr0nview
Version == 0.1.0

/etc/Desktop/menu/multimedia/pronview (symlink to /usr/X11R6/bin/pr0nview) should have the same metadata as the file it points to (automatically).

The idea would be that when you uninstall pr0nview, you search the filesystem for items that have the correct "Application" metadata and just delete those files. Another advantage as I see it is that it would be relatively easy to find applications. All you need is a tool that reads and searches through the metadata of files in /usr/bin and/or /usr/X11R6/bin.

Does XFS support a thing like this, or would we need to roll our own?

v fsckers
by Aitvo on Wed 29th Jan 2003 18:50 UTC
v Aitvo
by Strike on Wed 29th Jan 2003 18:59 UTC
"new Linux"
by jmf on Wed 29th Jan 2003 19:05 UTC

>Nathan 0. : I think someone would do well to take the Linux kernel, the GNU utilities, and X, do whatever they wanna do to them, and put it out as a whole new thing- not a new distro, but a new linux, mostly incompatible with today's Linux, but not untirely difficult to port to.

Such a project exists, see http://www.blueeyedos.com . To be short, it's Linux kernel + a reduced version of XFree86 + BeOs API; shorter, BeOS with a Linux kernel.
As far as I know, helps and contributions are welcome.

My opinion: GNU/Linux is missing a "benevolent dictator" like Guido van Rossum is for Python.

v Aitvo
by Eugenia on Wed 29th Jan 2003 19:10 UTC
Eugenia
by Aitvo on Wed 29th Jan 2003 20:10 UTC

I suppose I was a little over the top by telling you to shut the hell up, I apologise for that.

RE: Eugenia
by Eugenia on Wed 29th Jan 2003 20:16 UTC

No problem. ;)

Rethinking things
by HailstormXP on Wed 29th Jan 2003 22:28 UTC

This is exactly what MS seem to be doing at the moment. Grabbing a clean sheet of paper and rethinking the whole OS. Not scrapping everything. Rethinking things and then using existing work to form something completely new. However I think this is more from the pressure of knowing that people aren't going to keep on buying the same old again and again, even more so with the advances Linux has made.

I don't think it hurts to take this approach, indeed Nintendo actually develop their games this way. First they build their game and then they scrap the whole thing. They then start again but using all the experience they gained the first time round.

I certainly think that starting with a clean sheet of paper is good because it allows people to think outside the box. Otherwise you are bound to thinking, 'Oh no, scrap that, it'll break compatibility with so and so'.

4 real?
by anopenscroll on Wed 29th Jan 2003 22:44 UTC

Is there a real interest here in developing a viable Desktop OS, based on GNU/Linux?

4 real!
by Nathan O. on Wed 29th Jan 2003 23:19 UTC

In a word, yes. In two words, hell yeah! In three, I'd say so. Okay, so that was 4 dumbed down to three with a conjunction. Yes, there's an interest, at least from me!

The above link to the Blue Eyed OS looks like it might be neat, but all the links I click on load the same page. All I've learned of the project is that Guillaume Maillard has commited his changes to app_server... is there a little more in-depth page on this, or is my browser broken, or hmm?

Blue Eyed OS
by Nathan O. on Wed 29th Jan 2003 23:42 UTC

Wait, the page is working now. Looks pretty cool! Aside from the seeming tendancy to aim for Linux compatibility, I think this is exactly what we're discussing. I'd like to hear Eugenia's take on Blue Eyed OS, and how the idea discussed here differs from that project.

Blue Eyed OS
by anopenscroll on Wed 29th Jan 2003 23:47 UTC

Please have a better name than Blue Eyed OS... Seems to be going too much the BeOS route instead of linux, though?

RE: Blue Eyed OS
by Eugenia on Wed 29th Jan 2003 23:56 UTC

BlueEyedOS is indeed a BeOS-related project. It was created in order to recreate the BeOS experience. It doesn't start in with a clean sheet. However, it is the closest to what we are talking about here.

And a few days ago I was arguing with its main developer over ICQ regarding UI issues. Not exactly what I would call open minded person regarding UIs... ;-)
He would argue that using the keyboard for different actions, is enough for a media player to be "usable" and "user friendly". I did tell him that when the key "B" of the keyboard is used as b, B and for only one application as "go forward to the video timeline", is not exactly my idea of "user friendly". Of course, having keyboard shortcuts is imperative, but he was arguing that having ONLY keyboard shortcuts is enough to control a medial player, even if the app won't give you any other UI controls! He could not understand that a media player is an application that it would be used by whoever, computer-illeterate or not, so it has to be as easy to use as possible. The developer is a friend of mine, but what we would try to achieve, it would never fly with Guillaume in the helm. Guillaume is a _great_ developer, but not very good in usability issues.

BlueEyedOS
by Nathan O. on Thu 30th Jan 2003 00:26 UTC

I wasn't gonna say anything, but yeah, BlueEyedOS is a really lame name for an OS. In the system we're talking about, though, I think excluding the words "GNU/Linux" from the title would be a good idea, something like how Xandros isn't "Xandros GNU/Linux." Windows wouldn't be as "user friendly" if it was called NT/WindowXPSP1.

Exactly
by anopenscroll on Thu 30th Jan 2003 00:36 UTC

Yes. Look at microsoft. They have SIMPLE names like :

Windows
Office
Word
Money
Bookshelf

Can't the ubergeeks use SIMPLE names that mean something? instead of these, just for cd burning apps:

KonCD
CDBakeOven
XCDroast
GToaster

Continuation
by Nathan O. on Thu 30th Jan 2003 00:49 UTC

Personally, I really like this discussion and would love to see it develop in to a project all its own. The idea of a keyboard only media player is a pretty broken idea from the get-go. I don't think it's been mentioned, but what we're talking about here *could* easily go head to head with Windows in a few areas. You always hear about how Linux is making its way to the desktop. You never hear about a single part of the desktop experience that *IS* complete and usable by Joe User without the help of the neighborhood geek.

Since this newspost is going a ways down, can we move the discussion? I've started a little discussion in the Linux forum. It probably wont last long there, either, but wanna take it over there for the time being? I'd hate to see this discussion disappear with time. It'd be another one of those "well it'da been a good idea except no one bothered with it" things. Shame.

Re: What to expect
by Ludwig Maetzke on Thu 30th Jan 2003 02:02 UTC

Hello,

@Eugenia: What is *.doc? Microsoft Word text or Atari 1st wordplus text? Speak clearly, please.
Referring to drag&drop from/to a launch menu, I object that a desktop OS need not to offer such a menu. E. g. on my Apple Performa with System 7, I get all useful apps as file links in a dir with subdirs always open on the desktop and like it.

@shawn: In the German usenet linux forums calling the users there "snobby" is even friendly. I have never met so arrogant people with such few knowledge. If they run out of arguments or facts they flame "go back to Windows" even if you don't have a MS Win System at home. Queer.
Of course, I sometimes become definite, too ;-)

However, I bought a Linux distro some weeks ago and some fixes are already promised. The GNOME 2.2 screenshots look well.

regards, Ludwig

Re: Exactly
by Strike on Thu 30th Jan 2003 02:49 UTC

Yes. Look at microsoft. They have SIMPLE names like :

Windows
Office
Word
Money
Bookshelf

Can't the ubergeeks use SIMPLE names that mean something? instead of these, just for cd burning apps:

KonCD
CDBakeOven
XCDroast
GToaster


cdrecord is too vague?

re: strike
by jerkasaurus on Thu 30th Jan 2003 04:07 UTC

Quote: "Like that? And menus are generated according to the contents of these .desktop files. So, what you are asking for has been done already."

No, not like that at all. Those are nice xml files that only work with gnome. Make a symlink, which any app understands (because its handled at a lower level that user-space applications. Then it will not matter if a package creator makes the package install menu items - they will show up, because the "menu" is just a symlink to an applications folder. It will also not matter which desktop the user runs, kde or gnome or whatever, they will have items in their menu.

I've set up my macos 9 and beos installations this way, but it isn't something I can do in linux. I must create .desktop files, and move them around. Then when I install a new app, if it doesnt create the menu item, I must do it manually. If the "menu" is a symlink to a common "application" directory, no problem.

It was early when I wrote my first post, and now I'm boaderline braindead after an 11 hour shift at work...I hope this all makes sense.

Hiding the system is an act of cowardice
by Iggy Drougge on Thu 30th Jan 2003 06:57 UTC

Mike Hearn:
No end users should see the system directories at all.
Eugenia concurs:
But... I agree on that!

You're both very evil people.
But you can't really be blamed. You're both aiming at making UNIX userfriendly and desktop-oriented, which seems to lead to two paths:
1. Either throwing most of the innards out, keeping only core components. BlueEyedOS is a good example. It goes for core technologies but doesn't pay the userland much attention, instead implementing a metaphore entirely of its own. This is obviously not what Eugenia intends. She'd like to keep the toolkits, the POSIX compatibility (why?) and so on.
2. Hide the system from the user. If you want to keep the UNIX, the inherent complexity of the system must be hidden. So no insight into the directory structure. As a "power user", I find that a horrible suggestion. Windows does this, declaring C:WINDOWS and C:PROGRAM FILES as off-limits. MacOS X does this to a certain extent, but as always with a bit more spit and polish than the competitors. The original MacOS didn't do this, though. My mother isn't particularly afraid of the System Folder. Whether things are hidden or not is indiscernible to just about every user. It just works, and unlike Windows, there are (were) no droves of files with incoherent 1981-era names.

I, just like my mother, like to know my way around the system. But I don't like UNIX file system organisation one bit. It's not friendly. The multitude of /*/bin/ directories containing innumerable files is just one example. The naming of files is another one.

If a little though was spent on file system layout in the first place, even amateurs could find themselves at ease, and the developers wouldn't need to worry about the user getting lost inside the filesystem.
I prefer full transparency in a system, and I think that that appeals to most users, both newbies and pros. But for that transparency to have any meaning, the underlying mechanisms (such as the filesystem) must be clearly thought out and laid out. This isn't the case with Linux, but rather than declaring areas of the system off-limits, one should consider how one could make it more user-friendly.

I'm amazed that Eugenia, who claims to be a UI designer, doesn't think so. After all, don't you agree that predictable UIs are preferable over those which get in the way of the user, so-called intelligent UIs? Hiding underlying structures is the same thing. Make a UI predictable, and people will quickly reach a working pace.
This is also a kind of consistency question. A filesystem is a UI of itself.

Re: Hiding the system is an act of cowardice
by Hongli on Thu 30th Jan 2003 07:15 UTC

"As a "power user", I find that a horrible suggestion."

Exactly: as a "power user". But we're not targeting power users here, we're targeting "average users".

Why should average users have to know about the underlying structure? Heck, why do they even want to know? They just want to work with the computer, not trying to learn how the engine works. The menus and icons, that's what they should use. Is there any good reason why Joe Average should touch the underlying system structure?
Giving the system directory "easy" names only encourages Joe Sixpack to fsck his system because he *thinks* he understand it.

If Joe Average doesn't touch the underlying structure, then advanced users who know how to use the commandline (developers and power users) will. The advantage of the current structure for them:
- Easy to type (I can type /usr faster that you can type /System Resources)
- Easier to remember for non-English people (what's easier to remember if you're Chinese? /lib or /System Libraries?).
- Easy to understand. No you won't understand by just looking at it, but you just have to read a document for 3 minutes to understand what all those directories are! Yes, *3* minutes, at most.

RE: Hiding the system is an act of cowardice
by Eugenia on Thu 30th Jan 2003 08:01 UTC

My idea was to "hide" the system filesystem hieriarchy the way OSX and AtheOS and BeOS does it. When opening a terminal, you would be able to see and manipulate wdhat you want in the system (and even via file manager's path input box if you know what to type). The OS we are trying to describe doesn't "take away" from you ANY of the power Unix has. However, for the average user, he doesn't have to see all these "useless" for him system directories. So, when he normally navigates in his disk with his file manager, these dirs would be hidden. This abstraction works well with OSX and BeOS and AtheOS and has never created any problems to anyone. And power users still get to keep their flexibility they want. So, I really don't see your problem.

Why should average users need to know about the underlying directory structure, you say?

So that they feel in control. I believe that that's one of the reasons people don't like Windows and would like to hear about alternatives. It's a complaint I hear often enough. They don't feel like they're in control. The system is so much more complex than the surface might reveal.
One problem I have with OSX is that Apple implemented such a polished GUI on top of a relatively untouched UNIX userland. It's very unlike Apple, who have previously gone for a more thorough approach. It presents a very uneven learning curve. It's easy up to a certain point, and when you cross that certain border, you end up in a very alien environment. I don't know if they might have fixed it yet (though an interview with Apple's BSD guru featured recently on OSnews makes me believe that that isn't the case), but a year ago, Apple's command-line utilities were so rough in the edges that they weren't even aware of Mac metadata, which meant that the "mv" (a command used to move or rename files) command could cripple your files. That's what I mean.
If you decide to remain blissfully ignorant of the underlying structures for the rest of your life, you could get on with even today's Linux desktop distros without any problems. Just run GTK or GNOME apps, just install using the officially sanctioned package system, and ignore that XTerm icon. But this is no different from a Windows user experience. Perhaps not quite as polished, and it might even turn out that the user feels more in control in the Windows environment, but the difference is minute. But unlike the Windows desktopification developers, I've never been advocating that Windows might serve as a good model for a desktop environment. Most non-Linux desktop developers would seem to agree.

A sufficiently clear system layout isn't threatened by Joe Average. Classic Mac users seldom cause their systems permanent damage. I don't know how much magic the Mac system involves, it might be a whole lot, but it certainly looks easy enough to the user, and even a technical user as I haven't been able to scratch much on its surface. That's perhaps an important difference. No matter how hard you beat on MacOS, once you've reached the perceivable bottom, you can't go any further. Thus, I can't make any broad statements about how much of MacOS which actually is hidden from the user, because if it does hide anything, it's bloody well hidden.

Really, if all the user is supposed to use are the menus and icons provided, the Linux desktop user experience is just about finished as we speak; only the video players are yet lacking, according to last week's usability rant. But we aren't providing them with anything which they hadn't got on Windows in that case, and I think that it'd arouse much the same claustrophobic feeling which so many Windows users already speak of. One should at least induce a sense of clarity to the user at all levels, and a correspondingly even learning curve. Peak his curiousity, don't scare him away from venturing further. It's a question of demystification of the computer. Many - perhaps most - may prefer to just regard it as a tool, but if the user can be made more self-sufficient, that is a large stride in an often forgotten usability department, one which could become a strong selling point. Feeling is something which keeps people with the Macintosh (N.B.: I'm no Mac user, I just happen to know several.), and it's IME not just a question of familiarity, but a sense of control.

Besides, Eugenia isn't a Joe Average user either, and I don't think that she intended FooBarOS to be aimed only at that segment. In that case, I don't think that she'd have proposed such radical alterations to the current Linux architecture.
The power user might be a niche not quite catered to by Linux. Power users are, as someone else wrote a while ago in an OSnews article, non-programmers who still have much computer knowledge and are demanding about their environment and applications. It's a bit like the difference between M$ Publisher and Quark XPress. One is for the amateur, the other is for the power user. While overall system elegance might not matter much to the casual word processing and web surfing user, and while the programmer will have a programmer's mindset and be forgiving when it comes to obscure technicalities which show up, the power user treads the middle road, without the programmer's patience or the amateur's blissful ignorance.

As for the practical points:
-All modern systems, save BSD and HPUX, have tab-completion as standard. And you could use links or assigns to ease the burden on your typing fingers.
Besides, I see this as a general fallacy of UNIX. When I once complained that UNIX shell syntax was overly complex, requiring too much man(ual) reading, someone replied that I should just make an alias or a script.
That's an reverse approach compared to normal learning mechanisms, in which case the standard syntax were verbose to cater for newcomers, and then supplemented by briefer syntax or user-created aliases/scripts. GNU has actually done something in this direction, with its single-dash and double--dash arguments (though I personally find the dashes pointless).
-Easier to remember for non-English people. Quite probably. I'm not English either, and the laxness towards i18n in the open-source world is one thing which makes me steer clear of using its products more than necessary. But that's what i18n and localisation is for. Both the Mac and Windows have localised directory structures. It needn't be that difficult. Just make the standard directory names into localisation data. That way, a Japanese or Chinese system would have a directory name /x or something like that.
-I don't find the myriad of /something/bin easy to understand. And rather disorganised as well. This despite ten years as a computer user and running several BSD machines at home. I belong to the "keep all related things under on roof" wing. This makes installation and deinstallation so much easier as well. Once again, my preference for clarity in filesystems and related mechanisms shows.
Besides, saying that something is easy to understand after reading for 3 minutes doesn't mean that it is easy. If it were really transparent, one wouldn't have to read so much.

BeOS didn't support metadata transfer with cp and mv either. And BeOS' main feature was the metadata. Instead, it provided another command line util, called cpattr which did the job.

As I explained, the system dirs and files will be accessible to whoever is willing to do something with them. For the rest of the users, there is no reason to clutter their file manager for absolutely no reason. Don't forget that all operations should be done via the gui, so there will be little incentive for the average user to open a terminal and hack around the directories found under his filesystem abstraction threshhold.

@Eugenia
If the standard UNIX filesystem layout weren't so chaotic, that wouldn't be much of a problem. In this case, I see the flat layout, which usually is beloved by UNIX users, as a disturbance in the low-end user's experience.
There is no separation of functionality, that classic modernist concept. You have an all-unifying slash, which for some reason is stuffed with dirs of little consequence to the end-user, such as /usr, /bin, /etc, /opt, /old, /lost+found and what have you. These should really have all been stuffed into a /sys directory when single-user UNIXes first showed up, to keep the root tidy.
An example of this separation of functionality is the standard AmigaOS set-up, with a System and a Work partition. The System partition contains the system in its entirety, with its usual directory structure. Work is a clean slate for the user to populate (or pre-populated with applications). There is no need for the user to venture outside the Work partition in his day-to-day activities. Even Windows strives to do this by, albeit traditionally a one-partition set-up, isolating the mess it calls a system in a C:WINDOWS directory. The same goes for the Mac and its System Folder. Even UNIX seems to have strived for something similar, traditionally splitting the hard drive into a root and a usr partition, though this concept is put out of order by its cluttering of the root directory with system directories.
BTW, have you used the Amiga, Eugenia? It has an interesting solution to your idea of separation of relevant and irrelevant files. There are files with and without icons. Open a program drawer (folder, directory...), and it will at first display only relevant files such as the binary and its documentation. Choosing the "Show all files" option will however reveal all those files lacking icons, such as support libraries, plugins, locale files or data files. This makes the file system appear both as tidy for the experienced user and as accessible to the inexperienced one. It's a bit similar to the AppFolder approach of RISCOS or MacOSX.

I still think that even experienced users would prefer a clearer filesystem layout, though. And keep learning curves in mind. Many current OSes are like two alien parts welded together, but with an ugly seam apparent. Unlike systems designed with a GUI from the start, there is little rapport (excuse the francophony ;-) between the upper and nether regions in older systems (to which I count UNIX and MS-DOS derivatives).

OS designed with user in mind
by HailstormXP on Thu 30th Jan 2003 09:35 UTC

This has been really interesting to read. I think designing a new Linux kernel OS with usibility first and foremost in mind is a really good idea. Perhaps this discussion could be continued elsewhere?

cdrecord
by anopencroll on Thu 30th Jan 2003 13:06 UTC

Yeah... Like Joe User would use cdrecord every day?

Talking about the file system, I'm still having a lot of trouble trying to get KDE 3.1 started on my RH8 box. RH says something to put into /etc/sysconfig/desktop, whereas KDE says something else, and both don't work at all! Now you tell me, installing something should never leave this file-hunting job to me...

Video player
by Strass on Thu 30th Jan 2003 13:11 UTC

As it mention here, the case of video players will be soon closed. Take a look at totem http://www.hadess.net/totem.php3
An once gstreamer will be released (I mean a stable release as they said) everybody will be happy.

@Iggy
by Rich on Thu 30th Jan 2003 15:33 UTC

>> Why should average users need to know about the underlying directory structure, you say?
>>
>> So that they feel in control.

No, what you're actually saying here is that _you_ want to feel like you're in control.
(there's nothing wrong with that btw, but you'll have the CLI for that)

The average user doesn't care about that as long as it works.
(and that's my own experience with newbies / average users)

You saw it here first
by pnghd on Thu 30th Jan 2003 15:56 UTC

the birth of Eunix. :>

Eunix
by anopenscroll on Thu 30th Jan 2003 16:48 UTC

Hey, it sounds good as well!

Presenting..........................

EUNIX

Linux Forum
by Nathan O. on Thu 30th Jan 2003 16:51 UTC

There's a thread about this in the Linux forum for now, to keep it going until it can move to another place ;)

@Rich
by Iggy Drougge on Fri 31st Jan 2003 18:57 UTC

Actually, I was saying that the average user wants to feel in control. As I stated, many users I've met regularly complain that their system is doing things without asking first, and they have no idea how to correct it.

Naturally, I, too, want to feel in control. And I like consistency. I don't think that there's any need to have the GUI behave in one way and the CLI in another, when they both make claims to being part of one system. That's inconsistent.

Hey, great thread!

On the practical side, I would like to try an experiment
and if someone more knowledgeable wants to join, you are more than WELCOME!

Today I use Gentoo and my first experiment involves having applications, each with its own folder, in a common directory.

The scenario here is:
- When the user does 'emerge' the package,
he always finds the program (as a folder) in a common
dir (/opt/<package name> to stay with the standard).
Eventually, to make things really intuitive (dumb? ;-)
I would like to provide an /apps or /applications
linking to /opt.
This of course involves passing --prefix=/opt/<app>
to the configure.

- For the CLI to work seamlessly, links in the system
directories would be set using 'stow'
(thanks Peder, I was not aware of that tool!).
By sys directories I would use /usr/bin, /usr/lib,
/usr/libexec, /usr/share, /usr/doc... am I forgetting any?

Now the question:
If you know portage, how difficult would this be to implement so that it's transparent to the user and
automatically available for all packages, without requiring
changes to the ebuilds?

Well, this in my idea for a first step, just drop me a line
if you feel like helping. Thanks

Tom

Just as an after-tought, why don't we keep this comments on a TWiki somewhere, so that the thread can go on and possibly expand?

Hey, www.eunix.org is still available! :-P
Actually, jokes apart, the name fits particularly well, Eu means "good" in Greek, eunix, the "good Unix" ;-)

Nite everybody!