Slashdot Mirror
GoboLinux Compile -- A Scalable Portage?
LodeRunner continues "We already have ebuilds, RPM .spec files, and whatnot. The argument for reinventing the wheel yet again was the observation that while developing apps to handle these files is easy, the task of maintaining the ever-growing database of compilation scripts is the real problem -- the huge package collection of Debian comes to mind. Compile took the extreme minimalistic approach, and its scripts ("recipes") are as small as can be: the script for a typical autoconf-based program takes two lines.
Knowledge for handling common situations is usually added to Compile itself instead of being coded in the script (for example, apps that need a separate build directory just add a needs_build_dir=yes line). The plan is to make Compile as smart as it can and the recipes as small as possible.It remains to be seen whether this experiment of gauging differently the tradeoff between flexibility and simplicity will prove itself to be limiting or enlightening, but in the ~six months Compile has been in beta test by the people from the GoboLinux mailing list, over 500 recipes were written, ranging from Glibc and GCC up to KDE and the Linux kernel itself."
When i first changed to gentoo I was gladly surprised by the power and flexability of portage. If this is half as good it is worthy a place in the linux community, no doubt about it!
"Does away with" /usr/bin and /lib?
...In all seriousness, though, that does sound kind of like an interesting concept--might make things easier for people to understand. Me, I like my three letter unpronounceable paths all the same :)
BLASPHEMY!!! They're SINNERS! How DARE they mess with the SACRED directory structure! Et cetera! Et cetera! Ad nauseam!
But is yet another source-based compilation system needed?
Uhmm... I guess not, from now on, we'll do all of our compilations without source code... however that will supposedly be done.
mkdir /System/Settings
ln -s /etc/X11/ /System/Settings/X11
Couldn't this also work?
Yes, an autoconf build script contains two lines. And cannot express version dependencies that the autoconf build didn't think to maintain ... and if it did, it doesn't communicate the dependency back to the build system. It has no way to merge config files. It doesn't even have a way to enumerate the installations. But yes, you could build a system that simple, because it's good enough for some, but even slackware isn't that simple. To say nothing of distribution patches, configuration (e.g. to build xchat with gnome support or not?), and so on.
This isn't to say it'll get to be as complex as portage, but it will probably have to get at least as complex as ports. Which then begs an obvious question...
I've finally had it: until slashdot gets article moderation, I am not coming back.
I strongly believe in the jungle-evolution style of distributions, so I welcome any new randomness into the population to find out if natural selection will choose it or forget it... but...
I'm still not seeing what this has over Gentoo, other than the new directory naming scheme (which is, btw, very nice). Portage is a pretty slick system. Ebuilds are fairly simple to write. There isn't much in the way of "unnecessary extra" in them. Is this really that much better?
Education is a better safeguard of liberty than a standing army.
Edward Everett (1794 - 1865)
Just because you have a Unixish kernel does not mean you have to have a Unixish operating system.
Surprisingly, not everything in the world has to be Unix!
"Champagne for my real friends - and real pain for my sham friends!" http://ericblade.postalboard.com/
It's much more difficult to make a typo in /etc than /System/Config. That's one of the godsends of the POSIX structure over that of Windows - /lib is easier to remember/type than C:\Windows\System32. And there are none of those annoying spaces in /usr/bin that exist in C:\Program Files.
Having created build scripts in FreeBSD, Gentoo, Sourcemage, and Arch Linux, I think the most important goal is to use/develop a script language that newbies find easy to use.
If you're developing a new distro, and you're concerned about giving users a reason to move, focus on making it easy for us to add to the distro!
Check out my blog: My Galaxy is Milky Way Adjacent
I like how they post lost of screenshots running window managers. They could have just said "it runs KDE." It's not like their KDE is anything special, it's the underlying structure that's different. Then again, every distro does this. However, this distro is targetting people who most likely understand this concept already.
This system looks almost identical to the portage system in Gentoo, except without USE variables. Of course, I don't know that much about either system, but I don't see how this is any better (or even very much different) than the system that Gentoo has already developed.
Blasphemy my ass. i have been using Linux, BSD, nd other UNIX derivatives for over 10 years now, and all I can say is THANK GOD.
/usr/bin, /etc, /usr/local concept is totally outdated. Having apps in their own directories eases maitenence, eases administration, and eases uninstallation. Think about it, if apps were in their own self contained directories, who even *needs* a package manger? To install, you extract the tar, to uninstall, delete the directory. Boom snap, done and done.
The
Other than core system configuration and core libraries the whole system uses, I ideally think *any app should be totally confined to one directory level. IMO this is one thing Windows does right.
I would tend to agree that breaking the paths would be bad, fourtunately they don't exactly do that.
/Programs/Xorg/6.7.0 and /Programs/KDE/3.2.2. Each file category (executables, libraries, headers) can also be accessed through unified symlink views, such as /System/Links/Libraries and /System/Links/Headers. These views match the legacy directories (/bin, /usr/include, /usr/local/share) and so on, achieving total Unix compatibility while keeping program directories completely self-contained."
What they do is provide a more intuitive (on the surface of it, it seems so to me, need more details to be shure) path system while maintaining compatability to the old system.
"In GoboLinux, each program resides in its own directory, such as
They claim thier systems is path agnostic.
this is a good thing imho. One of my (minor) pet peves is that the standard *nix path system is largely cryptic to joe user, and a pain in the butt even for the cluefull unless you have enough *nix experience to make it automatic.
Now if they fix cut and paste and find a way to make havening both a *nix and a windows version as close as possible to a simple recompile with a few options/flags changed the year of linux as a major desktop contender will finally arive istead of forever being next year.
Mycroft
https://signup.leagueoflegends.com/?ref=4c3ed6600b6ea
The descriptive path thing sounds a lot like what OS X does, except that it goes all the way where OS X still has /usr, /etc, etc. although hidden. I wonder if Apple can patent or has patented that?
1. With Linux entering mainstream, hardly anyone uses the command line for things like file management anymore. They use file managers like Konqueror and Nautilus.
2. Even if you're afraid of X Windows, have you ever heard of tab completion?
Now try doing that with say, Nautilus
:P
Ooops! It's directories and files are scattered throughout the filesystem
Restricting programs to build into their own trees is an awesome idea IMO.
Yes, simplicity is good, but only in the context of the whole system. Here, you're just shifting complexity from the per-package scripts to the overall Compile package itself -- creating a large, central, monolithic service.
Because it's centralized, over time, this is going to accumulate a lot crap and become opaque, obfuscated, and unmaintainable. Changes and maintenance to Compile will more significantly impact the contemporary set of recipes than, say, changes to Portage and ebuilds.
It's easy to apply a good idea, like "simplicity", in too narrow of a scope -- to the detrement of the overall design. Better to think about it as balance of "package maintainability", "system maintainability", "barrier of entry", etc.
That doesn't matter much when hitting the tab key fills out the rest of the name anyway.
"Sufferin' succotash."
a distro that does away with Unix paths such as /usr/bin and /lib and uses things like /System/Settings/X11 instead
For all those thinking "what a nice idea":
afaik LSB requires FHS which, in turn, requires the standard directory structure. Does this mean we should throw the whole LSB out now?
And no, OSX is not LSB compliant - go figure.
When the poster mentioned
/System/Settings/X11
/System/Links/Tasks ,as the article mentions
/usr itself pains lazy idiots like me with the capital X; I shudder to think as to what'd happen if this, in case, becomes the standard (or the fad)
I had thought, he/she was trying to be funny
But the distro does seem to go this way :
Despite the intuitiveness, having capitals at the beginning of all the directories, particularly the ones that you are going to replace all the / dirs with, would be a major pain atleast in a case-sensitive *nix world
The current 'X11R6' in
(Karma be damned; I am no better than an AC anyway)
What's wrong with cut and paste? Highlight then middle button (or shift-insert) and you're done is the best cut and paste I've seen so far. Linux is ahead of the game in this area; using Windows drives me nuts with its four-key C&P, especially since Windows makes it hard to map the control key to where the caps-lock is, so every use of it really kicks the old RSI risk up.
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
I've recently switched from linux to OSX, and I've learned that the latter has some clever ideas (e.g. bundles) that can leverage developer effort. Given this context of learning by changing, my own view is that this new direction for linux is worth investigating ... not that I'll likely leave OSX anytime soon.
This is similar to the evolution from ant to maven for Java developers. With ant, you gave the steps necessary to build your system, an imperative approach. With maven, you instead describe the shape of your system, and it figures out the steps.
;)
Projects become more uniform as a result, and developers spend more time building the projects instead of maintaining build systems.
My only concern is the knowledge or experience that's lost as a result; larger and larger groups of developers have a smaller and a smaller understanding of the tools, environment, and subtle filesystem dependencies that systems tend to have, putting the experience in in-the-field debugging into a relative tiny number of cutting edge high-priced consultants.
By the way, I'm available.
To be fair, this isn't even a new idea for Mac OS X. It came from NeXT.
The filesystem is the package manager
With the simplistic file paths, and with a pretty decent amount of packages already, this is the distro that I might share with my friends. Especially since it's a Live CD.
After I get home from work, I'll download it & give it a spin, that's for sure.
Even if some might consider this a "dumbed down distro", this idea makes me thing that it could be one for tha masses.
Time will tell.
I'm in favor of anything that would help users find the dad gum files. I get lost all the time, I fully admit it. I even would go for full static programs, to heck with saving space. I *might* try this one out. Glad someone posted the article, I never heard of them before.
The current file system setup is mostly standard now. No matter what Unix variant you use its pretty much the same.. ( not exactally, but they are all close enough to get around them ) Why go and change it 'just because we can'. "Better" is relative.
---- Booth was a patriot ----
Nice, you just managed to enrage the two biggest groups of Linux zealots in one go. :-)
LOAD "SIG",8,1
The path is never set for /usr/local/bin by default.
It's like /opt in Sun environment.
Why not just install everything in /usr/bin?
The owls are not what they seem
But... but... "It's UNIX, I know this!"
In Soviet America the banks rob you!
Highlight something, left-click on emacs window, right-click on emacs and... nothing gets pasted because the stupid thing cleared the buffer when you left-clicked on the window in order to bring it into focus.
That drives me nuts.
The owls are not what they seem
From their web site:
The "differentiation" between /usr/bin and /sbin is hardly arbitrary. /usr is often on a separate partition; /sbin must be accessible even without other partitions mounted.
But the concept is interesting. I plan to download the .iso and give it a spin. (VMware is great for this type of thing.)
In the case of Gentoo, I treat the file hierarchy as follows: /usr: managed by Portage. /usr/local: software I can't get through Portage, that I install manually.
/usr for the system, /usr/local for all third-party software" approach.)
.profile is a poor reason to rag on a directory layout. I use ~/.bin for scripts and binary overrides, but since I doubt that's in your PATH, do you hate this too? :-)
/ and
Gentoo's file hierarchy is annoyingly loose, in my opinion, but this is common to most Linux distros. (I'm still a big fan of FreeBSD's "/ to boot,
However, complaining that you haven't set PATH properly in your
Fair enough, but what's the advantage?
complaining that you haven't set PATH properly in your .profile is a poor reason to rag on a directory layout.
The owls are not what they seem
Then many of the binaries in
Now
I don't see anything intrinsically wrong with a complete bottom-up rewrite of the current system. The whole point of Free Software and Open Source is that, if you don't like it the way it is, you can change it. Clearly the current GoboLinux system isn't for the faint of heart, but something really good may come out of it that would increase the usability of Linux by an order of magnitude -- but magic like that doesn't happen if people are constrained to the old way of doing things.
It may be that, in 10 years, most Linux users will be going "/etc? What's that for?". (hmmm. Some may already be doing that!).
Sometimes boldness is in fashion. Sometimes only the brave will be bold.
/usr/local has its uses. It's for packages installed by the user, which have nothing to do with the distro. Eg, my distribution comes with Mozilla. (/usr/bin/mozilla). This is used by eg Galeon, so I don't want to break or uninstall it. However, I do want the latest version of mozilla. The answer is to put it in /usr/local/bin/mozilla. (This is even more important with libraries).
Incidentally, Mandrake 10 does have /usr/local/bin in $PATH by default.
Yes, that is absolutely sweet and it is done that way for most third-party apps.
/System and remove files using it.
And if app needs to register itself as a handler for some mime type or for some protocol - it does it on launch, every time, so moving it doesn't break anything. Also add OS X links based not on path+filename but on uniq numeric file id and it becomes so nice and trivial...
Except that Apple itself for some reason insists on using pkg installers, which do nobody-knows-what and have not uninstall capability(*).
*Yes, you can parse receipt which is left after installation somewhere in
Sandbox for those of you unfamiliar with gentoo, provides a method for making sure that durring the build no file outside the directory can be written to, so malicious scripts (say someone cracked a project & changed configure for example) & whatnot wouldn't be able to work. It doesn't rule out trickier exploits (backdoors etc actually in the code) but does make it safer.
Now I saw no mention of something like that on the compile documentation. Does it have something similar & where is documentation on it?
Secondly, how does it handle minimum dependancies, eg kde-3.0.0 relies on qt-3.0.0 & similar things, & won't build on versions older than that. For example, looking at Abiword, It looks like you have to know EVERYTHING required & have that installed, with no way for compile to determine what Abiword depends on. If true, then that seems like a step backwards from any rpms, debs or ebuilds.
The authors apparently don't have a clue about ebuilds, otherwise they would try to use simplicity as this system's selling point - ebuilds are already there, they are about as simple as they can get if you want it to be useful for a real distro. Looks more like a manifestation of Not Invented Here syndrome than anything else to me.
i was also wondering if the concise directory names had anything to do with the smaller hard drives of the past. if so, then it would seem only natural to deobfuscate the file system now that we actually can.
sort of but not really, NeXT's filesystem had a difference in philosophy, this has a difference in naming conventions...
/stuff/include/foo /stuff/lib/libfoo.so
/stuff/foo/include /stuff/foo/lib/libfoo.so
where in typical unix naming conventions (because i'm lazy) you'd have something like
you'd end up with something like
different implementations of the same filesystem philosophy, like things go in like places...
imho the philosophy is what needs changing this seems like just a capitolized and descriptive maze
tho i've never used it so i can't really say.
I don't use X, you insensitive clod!
The only reason we have the rights we have is that people just like us died to gain those rights. -- Cheerio Boy
I don't know if anybody does this, but in theory I like the idea of a directory structure that mixes posix pathnames with descriptive pathnames. For example, everything could be installed into long descriptive pathnames by package, but the binaraies could all be symlinked into /bin the config files could all be symlinked into /etc and so on.
Because a) the behaviour is inconsistant (try cut and paste between several different apps, now try under windows) and everything has it's own cut and paste system almost. It's fine to have other systems available, but you need a consistant method that just works everywhere, or as nearly so as possible.
and b) what you just described is broken for many people. try cut and replace that way.
highlight to copy, then highlight what you want to replace, oh wait that won't work. I used a windows app that had to do it that way because the author hadn't figured out how to work a around a limitation in the programming system he was using. His docs Apologised for the broken behaviour.
And you don't have to use the ctrl key combos to c&p unless your mouse/trackball is dead. just a few mouse button clicks is all.
The highlight to copy thing makes assumptions about the users intentions, in a situation where there are other equally likely reasons to highlight, some of which require the clipboard to NOT be emptied. This is broken by definition.
Mycroft
https://signup.leagueoflegends.com/?ref=4c3ed6600b6ea
It works the same way for gpm
Give me Classic Slashdot or give me death!
Rox Desktop / Filer (GTK) does this for Linux, and the filer app (sort of Nautilus replacement) is blindingly fast too.
Scroll down to "Applications are directories"
Anything I compile myself goes in
Believe it or not, most things in unix are they way they are for a reason. That reason may not be immediately obvious to you, but it still exists.
While I'm used to the current paths, I have no hard feelings at all about ditching them.
I don't know if there's a linux standard for what kinds of files go in each directory but everyone I ask has a different answer.
I think switching to an updated naming scheme for directories and getting a common installation/uninstallation routine for applications that actually sticks items on the menus in the guis, etc. would be a huge move forward.
Not that I need either feature. I don't even use a linux gui. But someday maybe I will.
The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
Nonsense. Now emacs and vi: those are teh suck.
=-+
locate and/or slocate are excellent tools for this. You may need to 'updatedb' as root in order to build the initial database of filenames / paths, but then it becomes extremely easy to '$ locate filename', and is a whole lot faster than using 'find' to traverse the entire directory structure to hunt down one file.
See Filesystem Hierarchy Standard for an expanded explanation of the filesystem structure, though your distro may vary significantly from it.
As far as I can see by browsing a few recipes from your repository, you have not developped a special scripting language for it. It's simply bash scripts, with facilities through the usage of common variable and functions that trigger different behaviors.
If I take Armagetron recipe, for instance, it's not really that user-friendly in my opinion. Or, at least, not really more user-friendly than a Gentoo ebuild. Okay, the armagetron ebuild is longer, but it also contains more meta-data (dependences, license, architecture, etc) and it obviously has to install the program in the standard Unix file tree.
So basically, Compile looks like a lighter version of ebuild, but it is certainly not a revolution in the way you have to write the recipe/ebuild. I think GoboLinux looks different enough to make me try it one day, but in my opinion, the recipes do not improve much (assuming they do at all) from the Gentoo ebuilds to be as user-friendly as the inial poster said.
Disclaimer: yes I'm a Gentoo user, but still, kudos to the GoboLinux devs for making it happen anyway !
theefer
Comment removed based on user account deletion
Ok. I've never done that.
Upgrading an existing installation sounds like asking for trouble. I'll rather take a backup of my files, format the drive and install everything against. In my experience doing a partial upgrade will only screw up the installation anyway.
The owls are not what they seem
thank you for the link and the tips! Most of the time I don't need to find a file,just I am always wondering though where everything goes and fits in. Gradually starting to work out for myself how this all works together. I know if I had started with linux or unix many years ago I would know all this stuff, but I didn't, only started using linux in the "pretty good enough" GUI age, and as such, my knowledge of hierarchy and CLI is woefully lacking.
Question: Why not just install everything in /usr/bin?
Answer: Because then you can't manage different versions of the same package, or packages with binaries, libraries, or documentation that has the same filenames. Do you have any *concept* of how many different programs have a program called "check"?
I've always wondered if we can replace the Windows NT kernel and loader with Free ones based off Linux or HURD or something...much in the style of ReactOS, but with an MS proprietary operating system, non-kernel DLLs, etc. running over the kernel. Or if the NT kernel can run a fully POSIX operating system. GNU/NT or Windows/Linux, anyone?
where in typical unix naming conventions (because i'm lazy) you'd have something like /stuff/include/foo /stuff/lib/libfoo.so
/stuff/foo/include /stuff/foo/lib/libfoo.so
/stuff/foo approach, not the /stuff/lib one. (In very general terms,) in GoboLinux, /stuff/lib is a compatibility layer, or else "all apps would break".
[In NeXT] you'd end up with something like
Yeah, and GoboLinux does make the NeXTish "philosophy change" you mention. We follow (in your terms) the
The filesystem is the package manager
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
That drives me nuts.
It would! I'm glad it doesn't happen on my machine. What WM are you using?
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
Er, no, it doesn't 'beg' the question. It raises it without answering it, certainly; but that's not what begging a question means.
Begging a question is assuming it, using it in a circular argument.
[pontificate mode: on]
I find it strange and depressing that a community which is, in general, so careful and precise about its use of computer languages, should be so cavalier in its treatment of human ones...
Ceterum censeo subscriptionem esse delendam.
It's George!
(tig)
Ignorance and prejudice and fear
Walk hand in hand
The advantage is that you can mount /usr/local via NFS. Install the program in the exported filesystem on the file server, and then all the clients automatically get the program installed as well.
There are some applications which just don't use the protocol the same way; but this is becoming quite uncommon since emacs was fixed. There is also a content negotation system for negotiating what types of content can be pasted where, which KDE and Gnome both support.
One remaining difficulty, with Gnome at least, is that when an X client exits, its selections disappear (so you can't copy, close the app and then paste).
For more info see here.
I take that back, I was thinking about it backwards. It's been a long day. /usr is to be mounted on the server, /usr/local is then mounted locally for local packages, hence the name local.
/usr is an abreviation of UNIX system resources.
/home. The names are shortened because there was a maximum length on filenames in UFS - 12 characters I think, or there abouts.
/sbin and /usr/sbin should be clearer. That is, /sbin contains those special programs (e.g. init) and administrative programs (e.g. fsck) that would be reasonably needed before mounting another partition in the bootup process. Once /usr was mounted, the majority of the system binaries were in /usr/sbin.
The abreviation of user you're looking for is
If I note that sbin means system binaries (i.e. the minimal set of programs to get booted, and administration programs), then the existance of
That's not to say that it was a good idea, or that it is a good idea, but that's why it's the way it is.
The one good thing about such a standard is that I can get put infront of any flavour of Unix (or unix-like system), and do basic sysadmin stuff, like configure a network, install sshd &c. This was very useful when we were getting a lot of odd machines for work - I've used 8 different 'Nix varients in anger, without any documentation save sometimes some man pages installed. That's what any new filesystem layout must compete with - portable knowledge (same sort of thing that helps keep X11 around).
To end, I'll agree that the current windows set up for where files go is, indeed, very nice. The problem is the few applications that don't care, and user hardcoded paths. Those (legacy apps, if you will) cause a lot of pain, and is why most people I know are administrator on thier boxes all the time. It's been caught by, essentially, lazy programmers. I expect that similar problems (although hopefully disimilar solutions) will arise with any Linux distro that moves paths around.
I think you didn't read what the first letter in 'LSB' stands for - Linux
Not exactly. Like Win32, LSB is a set of application binary interfaces, one for each of several CPU architectures. Any system running on a supported architecture can implement an LSB compatibility layer, just as Wine implements Win32 on select operating systems running on i386 CPUs.
The LSB FAQ answers the question "Is the LSB only for Linux systems and applications?" thus:
You should look at rox which advocates and uses an appdir apporach in unices (which is actually really neat and effective, they even provide ROX-LIB which shows how it would work with repect to libraries.
True, libraries would still have to be in some common area, but at least would have all relevant resources entirely contained in a subdirectory.
OSX does some impure global resources stuff and some things (particularly Apple packages) are installer based and contribute to tossing things all over the place...
XML is like violence. If it doesn't solve the problem, use more.
well, a good idea for a desktop system with average joe blow who thinks deleting a buncha files is the best way to uninstall some shit, (often run into that with broken windows systems)
so if they wanna suddenly be mr. computer expert with their son's computer, they wont completely fuck it up.
That works on any Unix based system.
If need be then a distribution could be packaged up from the portage system, so that you could generate rpm's, deb's or gentoo files from the higher level.
If I look at System/Executables/Zsh/Settings or whatever they call it, I am catapulted back into c:\progra~1 world.
Are they considering backups? I don't want to backup the binaries, and I don't want to write endless lists of inclusions or exceptions.
Or are they going to "fall back" to the legacy tree, which was designed to be exactly that: a tree logically divided into groups that make sense to a system.
I don't get it.
echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
I would have to agree.
Running RedHat or anything of that sort may be okay for the single multimedia workstation you keep around for your evening entertainment and the children.
But as soon as you have more than one computer to worry about -- possibly geographically separate -- the colourfulness and one-clickability quickly yields to major management pains.
I personally don't even understand how Gentoo can hold strong. When I think about my personal 17 machines, spaced across five countries in three continents, and the 47 machines I administer at university, then there is only one logical answer. Debian.
echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
I generally don't think it's a good idea. It's additional clout that is pretty much unnecessary, seeing as how everybody is already used to /usr/bin, /lib, etc. If there were an advantage, I'd go for it, but there isn't: It's longer to write, you're mixing upper- & lower-case letters, and it's confusing sometimes. No real advantage.
Take OS X for instance. Here's a sample of what's in my root directory on my Powerbook:
/Applications
/Desktop DB
/Desktop DF
/Developer
/Library
/Network
/System
...
etc.
It's confusing and convoluted as hell. There's not necessarily only one type of file in each directory. Not to mention the structuring: there are applications left and right, many of which are actually directories containing more varied data. Madness, I tell you.
Stick with tried and true. It's been proven to work, and there is no major advantage over the new method.
It doesn't matter what you call system directory names, because at the desktop level and below, the average user just won't care. In other words, the typical newbie will never encounter /etc or /usr/lib. It may sound nice at first glance, but this is not something that will make the system easier for users.
/usr/X11R6/lib/fonts, because the user is going to push the "install font" button instead!
At the "desktop level", however, it does make sense. And oddly enough, this is an area where the FHS and tradition are completely silent. Do what you want and no one will care.
The user isn't going to care that system-wide fonts go in
Don't blame me, I didn't vote for either of them!
I hear those are much better than GoboLinux. Can anyone confirm?
creation science book
I agree with you.
Computers are supposed to be our slaves. They should serve us in the way we like them to. I would like Linux to have directory names that are clearer and help me figure out/tweak/fix my OS more easily. I should not have to bend my brain just so the computer can have an easier time.
Off the top of my head, computers do two things:
- Help us do things that are otherwise impossible.
- Help us do those things faster, more efficiently or more easily.
When you can help people use their computers more easily by making the directory names intuitive, you should go for it. It would be great if a person of average intelligence can understand what a certain directory in his OS is used for without having to memorize anything. As you know, human memory is weak and the memory of an arcane directory structure will break if not refreshed often enough. People will like Linux more, explore their system more and will make less mistakes if the directory structure is human readable.
I guess that when you're a kernel hacker, you tend to forget that it's BOTH about the end result (a nice slave) AND the correct/elegant way to achieve that result because you're spending your time mostly on the how, not the ultimate why. I don't know how the traditional directories got their their names and why they were born but was it all thought out logically? Was there a plan and good reason for doing it like this? Well, they did think about the new way of doing it and they have good reasons.
Let me give you another argument. Linux advocates often say that one of the strengths of Open Source is that there is diversity and that the forks and experiments strengthen the software ecosystem. Well, that 'Darwinism' will only work if you select the best 'mutations' and discard the "old organisms" that didn't work. I think that everyone with an open mind would agree that, from the end user's point of view, 'programs' is better than "usr/bin". If you don't select a new way of doing things once in a while, what's the point of experiments and diversity? You might as well keep things just like they were in the beginning forever.
I know switching will be painful because of existing applications but Linux doesn't have 90% market share yet. I know it will but my point is, if the painful switch to a new directory structure is done NOW, it will inconvenience a lot less people than when it would be done when it's the most popular OS on the planet. On top of that, I think it will help Linux achieve that 90% faster.
The computer should be my slave and bend over backwards to please ME. It should use more processor, memory and storage to please ME. I should not have to waste more time, think harder and be aggravated JUST so the PC has an easier time (has to use less storage/memory/cycles).
I will give you one final example of why this way of thinking is good in my opinion. I've been computing in Windows 2000 until now because I've started with Windows, because Counter-Strike and Photoshop are Windows (Mac) only and because I think Linux would cost me more time and aggravation than keeping Windows patched and cleaned. However, I have been keeping an eye on MaxOS X, Linux and other Open Source operating systems like FreeBSD because I know they're better from a system point of view. Also, I know that Microsoft have done evil things and I'm convinced will do evil things in the future.
I have decided to switch to another OS because of ROX and GoboLinux. I'll try different combinations of GoboLinux, Rox, FreeBSD and installed Knoppix and decide afterwards. (any suggestions for a beginner?) If that doesn't work out for me I'll have to save for an iBook.
I'm not too proud to beg so please help make the the world a friendlier and less MS place and open yourself to that "discard the old and embrace the better" mentality that you demand of Windows users. Support and advocate the ROX and GoboLinux way.
Slightly offtopic: Some people argue against the "every file of a program contai
- -- Truth addict for life.
I believe that they don't have any solution for popular problems like name/version conflicts with libraries and header files, so GoboLinux can't be an alternative to Gentoo Linux, which at least has a slot concept making it possible two different versions of the same package to co-exist.
At least, so long as the system uses shared libraries.
:P
MS-DOS was the only OS(that needed an install, Atari DOS wouldn't count there) where I really had a "clean" install the whole way through. Programs went in x, drivers in y. Everything using DOS4GW had a copy of it included with the binary, no harm done. Needless to say, configs also went alongside the binary.
Of course, this falls apart as soon as you have a more complex OS that needs things like scripting languages and windowing systems. There's just no way around shared libraries. And with shared libraries comes other kinds of shared access - to data and devices. So you have to reorganize, create new structures to hold certain kinds of files. Version conflicts, missing depends - all result from this necessity.
Of course, these structures just won't make any sense to the end user, except as a programmer. It won't matter how much you try to polish it up. A project like this might help, but putting an end to it all would probably need something along the lines of an FS and binary format revision, to include more data like the version number and purpose for each file. Good luck doing that....
Why don't you just download the source to and compile your own? Is it really that much harder to "check" the SATA RAID support option in the kernel, compile and install than bitch on slashdot about it?
SATA RAID doesn't seem (to me) like it would be very common in most environments (since the ID in RAID means "inexpensive disks", and last I checked SATA drives were still pretty pricey). Anyway, if you're in an environment that requires such specialized (high-performance) hardware, you might want to be tweaking your kernel anyway.
Unix has provided this feature for YEARS. It's called "ln -s". You can use it to create an alternate directory structure to your liking, and still keep the simple, short, easy to type, common file structure that we all love.
As far as the package manager, it seems to me that it (like all other package managers) is just reinventing the wheel. "./configure;make;make install" is pretty easy. Most reasonably well written configure scripts already check for dependencies. If you want to write a really good package manager, design one that parses the configure and make files to build a dependency list and present the user with build time options. Include a defaults capability (like Gentoo's USE variable) so that the package manager bugs you less about what options to choose when configuring, and you are all set. The package manager then just does the "./configure;make;make install" for the user and it's done. The only problem are any programs that have poor configure scripts (or those that don't use them). Since the package manager would likely have to hit some central library to be made aware of what "packages" are available and where to get them, this library could contain custom info where needed (read: a proper configure file, or a dummy one if the "package" is just a script that has to be copied to a directory, etc).
Oh well. Hackers get bored if they aren't reinventing some wheel, trying to make it better. And, admittedly, some package managers have some handy features that may qualify as better (allowing for precompiled binaries for the impatient/lazy is one of them). Who am I to judge?
Oh, was that my outside voice?
Done a ./configure lately?
You are being MICROattacked, from various angles, in a SOFT manner.
they allow me to procrastinate by looking at someone else working.
Ever have a vital piece of info destroyed because you accidently hit the delete button.
Ever accidently overwrite a file because you saved with the wrong name and didn't realize it.
This is why I see a problem with silent actions like how the highlight/middle click works.
Not necessarily as disaterous, but it still takes a non obvious assumed action with no feedback.
It good UI design to have clarity of action and response. People make mistakes and click the wrong thing from time to time and the dumping of the clipboard into a document because just a little to much pressure was aplied to the mousewheel while scrolling is plain asking to frustrate the user and bad ui design.
I'll grant that mousewheels that act as a middle button probably didn't exist when this was started, but that still dosen't excuse it still doing that on a single click.
From your last paragraph it seems as though the situation might be improving some. But you can understand my frustration when a recent set of apps (mandrake 9.1 install) couldn't even share TEXT through simple cut/copy and paste. I don't mean obscure apps, I mean a browser, a file manager and a text editor and other apps that SHOULD communicate simple text easily.
One last partial tangent to this. Choice is good when optional, not when forced for everything. To make an analogy try going to a few stores, start with general stores that don't specialize and notice how limited thier selections per item are. Then goto a few specialty stores that cater to people with specific intrests and likely specific knowledge. notice how broad thier selection is and consider how daunting that could be to an outsider.
Mycroft
https://signup.leagueoflegends.com/?ref=4c3ed6600b6ea
You just made the path longer. How convenient!
/^([Ss]ame [Bb]at (time, |channel.)){2}$/
I think the strongest case for using an organization like this would be for building large farms of clusters, diskless and dataless clients
A more radical approach may be to use a combination of this implementation along with peer-to-peer technology
For core system stuff (bash, textutils, etc) or for anything I don't fear having to upgrade very often, I've tended to link static. The other good thing about this is that I can make a static skeleton for one system, copy it to another partition, and it works with a minimum of additional needed screwing around.
As the above post says though, for X or anything GUI, shared/dynamic is the only way to fly. The reason is that GUI stuff generally has an enormous list of dependencies, and so attempting to upgrade with everything static would break down very quickly, because when you upgrade a single lib, you have to recompile everything that is static but that contains the earlier version of that lib.
Shared linking to me for the most part is a pain in the tail in a whole lot of different ways...I agree with that, and it of course was the source of the dreaded Microsoft "DLL Hell" problem. There seem to be ways to minimise it, but at times there doesn't seem to be a way around it.
Not sure if this is a good idea, but here it goes:
Directory entries could be presented to the user in his/her native language after the fashion of gettext -- i.e., the language/locale of the text would be determined by some environment variable, configuration setting, or command issued by the user.
Imagine a user who speaks only Mandarin Chinese. Suppose he gets a list of directory entries at the root level. There he would see the Chinese words for "System", "Applications", "Library", etc.
Later, when an English-only speaker uses the same machine, he'll see the same directory names in English, either because:
1) He logged into his own account, which is set so that the OS presents everything, including directory entries, in his language and locale, or:
2) He issued some command to change the language during the same session with the same account.
Normally, this would be difficult to implement (and have it work everywhere in the operating system -- not just while in a special desktop environment). But maybe Reiser4, with its plugin architecture, will allow the job to be done with a small amount of effort; see here:
http://www.namesys.com/v4/v4.html
With the combination of this implementation and peer-to-peer technology, a system could be built with all of its components being relocatable... existing locally or remotely in more that one location
But, taking a page from the BSD ports collection, you could have modules distributed separately from the "monolithic service" that define common packaging conventions. There could be a description of how to build "standard" autoconf-generated packages, which might be referenced by the more specialized description of how to build gnome packages, and so on.
This way, you would have the advantage of not having so many duplicated descriptions to maintain and you would also avoid having a monolithic kludge.
Note that I am open. I know Debian is elitarian, and I try not to be. What I wrote was simply from experience. But I don't know Gentoo other than from the stuff I heard about it.
So how do you admin 20 systems rmeotely in Gentoo, in a timely fashion pertaining to updates, and without too much time invested?
echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
Classic Mac OS goes a long way. Application folders can be dragged and dropped, and dragging the OS folder to a newly formatted (external) HD effectively clones the system.
I didn't use the OS that much, so there could be downsides, but it was quite impressive
Wouldn't this eventually require system kernel changes and an eXtensible Stack-Module (in short excess-module)?
I mean, just try to imagine the lengths of that PATH-variable after every single tiny little GNU-app should have a own directory with added path. You'd probably end up needing a Oracle dB-server extension for the basic PATH-system...
The CLI performance would end up so beyond any overbloated GUI, that people wouldn't even dear putting the terminal icon on their desktops.
Except a couple of things. First of all it doesn't. Second of all it's all a matter of taste. I'm love the POSIX way and I getting increasingly fed up with windows pseudo-organized structures.
When you don't make the system consistent, it quickly ends up (a lot) worse than any bad, yet consistent system.
Not Buzzword 2.0 compliant. Please speak english.
Because the INSTALLER kernel is built into the ISO, and there's no support for the disks. Additionally, there's no support in the INSTALLED kernel, so even if you get the installer to install to /dev/ataraid/d0p0, the kernel, once booted, won't support it.
How do you bootstrap the system w/o initial support? Hmm? Sounds like YOU'RE the one who's never compiled a kernel, or done an install short of simply booting the CDROM.
Oh yeah, troll.
I want to delete my account but Slashdot doesn't allow it.
Think about it: "Unix System Resource(s)" isn't merely historically inaccurate, it would also be an absurd choice of name given that it no more applies to /usr than it does /bin, /etc, /lib, /var, or /sbin. (/etc used to contain everything now in /sbin too. Can you imagine what a PITA that was?) And why put "Unix" in the name? It's not in any of the other names, and they're all (or were all) unique to Unix!
While this particular myth is a little annoying, it isn't half as bad as the collegue I know who thinks the correct pronounciation of /etc is "Ett Sea"...
You are not alone. This is not normal. None of this is normal.
You are not alone. This is not normal. None of this is normal.
Nice, you just managed to enrage the two biggest groups of Linux zealots in one go. :-)
And was stomped into the ground accordingly:
Moderation -2
50% Flamebait
50% Overrated
Nice combo.
Well, a poster further down is of the same opinion as me - and then - should I trust an AC on /. or the Linux Documentation Project? "Unix System Resources" is a backronym invented some time after the /home subdirectory was introduced - "user" is now a wrong description for /usr.
Why the flame?
I was just offering my suggestion. If you don't like my suggestion or don't think it applicable then you are free to politely refute my suggestions in a reasonable manner.
You're right though in that I didn't think about bootstrapping the system (I've never had trouble with the default bootstrapping kernels, so I didn't think about it).
But you'd be mistaken if you think me a n00b "who's never compiled a kernel, or done an install short of simply booting from the CDROM." As a stage-1 Gentoo user (running a manually configured 2.6.5-r1) I like to think I can claim some small degree of Linux knowledge.
But after thinking about your restated dilemma, I thought of three potential solutions (that you are free to shoot down):
1. Install to another harddrive.
Does your root filesystem *really* need to be on the RAID array? Get a separate harddrive for the system files (which, since they can be restored from the install disk, don't need to be redundant, and probably won't need the performance boosts from the RAID array).
2. (Minimal?) Install on another harddrive, and copy over.
Slow, painful, but effective. As you copy over, you can replace the standard kernel with your custom SATA RAID kernel.
3. Use your own kernel for the install, and install (with your kernel) to the RAID array.
Either use a boot-floppy with your kernel in conjunction with the distro's install cd, or make your own variant of their install cd, and all should work normally. Adding your kernel to their install cd, and remastering shouldn't be that hard (and you can probably find detailed instructions via google, or by emailing your distro). If you do remaster the CD you could post it online (assuming you're using a free distro...) and then no one will be able to bitch about this issue with that distro again.
But of course I'm probably wasting my time replying as my brother thinks you're "one of those ogre-people" (trolls) he read about in his "Net Force" book.
someone mentioned containing apps in their own directories instead of the traditional /usr/bin stuff... but i thought unix favours having "kernel" and "everything else" so that we have small apps cooperating to get stuff out?
So unless we want to settle for a cocktail, I find it strange to try too hard to "isolate" proggies, afterall, libraries aren't the only thing that gets shared in unix, we have lots of CLI's and shell scripts running stuff and what not... no, I wouldn't like to see "ls" getting its own directory, nor would I like the idea of "primary" and "secondary" applications...
I think the current system does well - mnemonics work well for both English and non-English speakers - afterall, I don't think we want Red Flag Linux to start naming their FS in Chinese and put up an impossible barrier to entry in their market...
It's obvious to any experienced Unix users that highlighting text copies the text to the buffer. No reason to waste effort by making such minor things overly complex. You can still use the right-click menu in most apps to access additional C&P options. Wasting effort 100% of the time because people make errors 5% of the time is bad design and that is what it'd be to have some sort of confirmation on cutting or pasting.
:P
I cut and paste text between browsers, email, editors, etc all the time with rarely a problem. Certainly less problems than I experience doing the same in Windows. Just try C&P'ing from a DOS box.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
Except Joe Sixpack isn't an experienced unix user. .1 second beats a mess that takes more than 2 seconds to clean up 5% of the time.
I wasn't refering to a confirm dialog, just make it obvious what's going on. Useability through Obscurity is a non-sequiter. An extra step 100% of the time that takes
I can understand how such a 'feature' wound up in an OS based on the posix standard. It's been around a long time (for Good reason). But computers are no longer the domain of educated specialist, and quirks that devolped for limited resources that an experienced user can adapt to will completly turn Joe off. Now if you just want *nix for the geeks, and see no value in a version for the masses that's fine. I however do see a value in it and am interested in improving it.
And it's not even the minor nit about how that version of c&p works per se. It's the lack of a consistant, dependable, mechanism that Just Works, the same way, everywhere. It's what joe sixpack is used to.
And just because Windows has one break in it's c&p does that somehow invalidate improving what *nix has?
Still it has shown signs of improving, I'll probably be buying a boxed distro with the 2.6 series kernel and newer versions of Gnome and Kde sometime soon and checking out how far things have actually come since I last did so about 6-10 months ago. Don't have the bandwidth out here to d/l a whole distro, even the small ones
My goal here is NOT to disparage *nix, but rather to point out an area I believe needs improvement to make the modern *nix ready for the common desktop, it's very close right now and the main things holding it back seem to be variations on elite-isms and sacred cows.
But really this is a fairly minor thing compared to some of the few BIG problems still remaining.
Mycroft
https://signup.leagueoflegends.com/?ref=4c3ed6600b6ea
I have no interest in converting the world to Unix. Anyone that can benefit from the tools I help refine then great.. but I'm not going to dumb things down for them. Anyone can learn.. I'm willing to help them.. if they are unwilling then let them suffer for it. I'm not going to sacrifice usabilty by me for usability by others.
.1 seconds because your mind has to register on what pops up, select the right choice, and then click. Would you also suggest that for every keystroke combination that a dummy 'did you really mean it?' dialog should pop up?
Clicking even one extra button takes more than
I will agree though that there should be further work on working out the little glitches. Most have been fixed for years now but some still exist and it'd be nice if they didn't. I'd also like to see highlight to copy extended to include non-text.. like in the file manager. Any place you can highlight something that should copy it. I'd also not be against an easy universal way to disable highlight to copy.. for those that don't like it.
My biggest complaint about Linux on the desktop is that it sucks almost as much as Windows or MacOS. Cloning those interfaces is not the way to embrace and extend the desktop concept. You can't win a race by always following. We should concentrate more on enabling faster, better, more flexible access to the information users need rather than on trying to imitate the look and feel of Windows. I still get most of my work done on the command-line and that seems to be the major failing. The power of the command-line needs to find the ease of use of the desktop.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
I never meant to imply that useability should be reduced. Other than your good suggestion (being able to turn it off) Another way to 'fix' the highlight issue would be for it to say be moved to highlighting with the middle button to copy and maybe setting paste to be a double middle click or somthing else a bit more consistant and less prone to confusion. The option to change it to suit the user should always be available IMHO.
As far the dialog thing goes, I believe I arleady explained that. A dialog per-se is not always needed, but the fact that somthing other than Just what you see is going on should be communicated to the user, somthing as simple as a little icon somewhere visible, but non intrusive. Perhaps followed by "use middle button to paste a copy of highlighted text in compatable applications" in a status bar or some such. just tossing out ideas here.
Your whole last paragraph is very close to my thinking, the only thing in it I MIGHT quible with is that it comes close to implying just because Microsoft or Apple did it's therfore wrong, but based in part on "We should concentrate more on enabling faster, better, more flexible access to the information users need.." I seriously doubt you've made that mistake. Personaly I think one should evaluate a tactic on it's own merits, not on who else has used it.
As far as dumbing down, far from it. What I'm looking for is a simple streamlined intuitive interface that Joe sixpack can sit down and use, yet a power user can go in and set to exactly his preferences through an equally elegant intuive system. It can be done, it's just not as easy or attractive to many coders as the apps themselves usually are.
I'd like to point out that Joe six-pack has the power to make the big companies sit up a pay attention. If Joe say Linux is how things are going to be, The companies WILL develope for linux, and some of that will be Open source if for no other reason than better Linux makes thier software more attractive to Joe and his wallet. If however Joe goes blithly along with next bug-ridden virus prone drm loaded redmond offering our lives don't get any easier. Joe outnumbers us millions to one.
And to this:
"The power of the command-line needs to find the ease of use of the desktop. "
All I can say amen brother your preaching to choir here.
Anyway I've put a rough draft of some of my thinking from which much of my point of view on this comes from in my journal if you care to check it out. I suspect in broad terms I dissagree you less than it might otherwise seem, just a few details.
Mycroft
https://signup.leagueoflegends.com/?ref=4c3ed6600b6ea
The ability to change the buttons required to highlight to copy, add icons or dialogs, etc would be fine IMO to make all easy through the UI but I'd leave the default as it is. Individual distros could feel free to change the defaults if they thought it'd please their users.
:)
I think most of what Microsoft and Apple do is bad.. not everything. Microsoft's pie in the sky vision of a db based OS is closer to what I do on my systems and I think closer to what the Linux desktop should be targetting. There should be less concentration on eye candy and more on enabling the user. It's fine to have eye candy, when appropiate, but it shouldn't be more important than the purpose of a computer which is to manage data of all types.
My first suggestion is to make UI oriented tools for working with (or reimplementing) popular command-line tools and creating an easy graphical way to string those tools together. Pipes are powerful and easy to use and IMO well suited to a graphical construction tool. Go ahead and make it easy to create new modules that can be piped together. Make it so these modules can be bound to menu options either on the desktop or even in programs. Make modules that can index, search, and variously access many different types of data from the local filesystem or from the network. A user should be able to create a desktop button that will instantly find all music on their harddrive, eliminate anything that wasn't by X artist, and play the remaining music in the default music playing app. Something like that should be buildable in a couple minutes time for an average user. Three commands: locate '.mp3' '.ogg' | match -artist 'X' | $DEFAULT_MUSIC_APP should be all that needs to be done.. these modules just need made and added to an easy GUI.
In relation, I'd also beef up automatic indexing of data the user uses.. on the local machine and the network. There should be a database kept with important file and network resource data indexed for quick searching.
The user shouldn't have to know what program they are looking for.. they should be able to just select the file, or file type, they want to work with and the associated app(s) should be listed.
Virtual directories listing recently used documents, programs, network resources, etc should exist and be easy to create. This is Unix - take advantage of 'everything is a file' because it'sa powerful concept.
Simple commands with pipes and everything is a file. The Unix way. Why is the desktop not following these key concepts? If only I had time to implement my own desktop.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
Honest to god... I'v been using UNIX for 20 years, and I've never heard 'Unix System Resourses" applied to /usr before today. (at least -- not that I remember!).
Free Software: Like love, it grows best when given away.
Well, I figure that BeOS has a somewhat Unix-like kernel, and was really not so much of a Unix-like operating system. My thought was that it actually took all the bad things about Unix, and combined them with all the bad things from other operating systems. (i've never spent more than a day figuring out the basics of an operating system only to get frustrated and give up.. except with Be.)
So, why couldn't the kernel be mated to a completely different set of software?
GNU already runs on virtually all versions of DOS/Windows...
"Champagne for my real friends - and real pain for my sham friends!" http://ericblade.postalboard.com/
Can't speak to what apple does. But I will agree that alot of what Microsoft does is eigther bad (automatic running of e-mail, default to root on boot up, etc.) and even thier half way decent ideas are often broken in implementation (the registry, add/remove programs, so on). I'm not just referencing thier programming when I refer to thier tactics though. Take the whole embrace and extend they use for lock in. Linux could simply do the same by creating much improved versions of apps found in the windows world for example.
I've actually seen tools a little like what you mention in your search-grep-act example, Mostly in news readers though. The whole concept is somthing I'd like to see as well. If a proprietary newsreader can implement stuff like this on message filters, it should be possible to do somthing like this on the linux desktop.
The reason why powerfull concepts like this are not on the desktop have to do with why alot of people work on open source. It's an ego game to some degree, and shiny pretty widget that do somthing trully new clever are more ego points.
The rest are mostly making some specific tool to fit thier own needs, once it's 'good enough' for them it doesn't get as much attention from them, the person who understands the code best.
Of course these are just two factors I see, I'm shure there are others.
A user in general should have to know as little as possible. The lower bar to entry the better. Now this doesn't mean a knowledgeable user should be locked into an idiot box without access under the hood.
In fact we largely have eigther the idiot box, or the opposite end of the spectrum. And this problem I see as endemic to most software these days, not just winodws or linux. It's bad, there should be as smooth a graduation from idiot noob to HighWizard Guru as possible. The minute I want to do more than choose between eye candy setting I shouldn't have to edit obscure setting in a file or hack the registry. The "advanced" options shouldn't be just whether or not the menu's are animated fast or slow.
The news reader I'm thinking of up there is Microplanet Gravity. The original company died, but a developer got to keep a full copy of the code and has rights to most of it. I beleive he was looking into Open sourceing everything he had full rights to once he could replace code he was only alowed to use, not open and modify (probably proprietary libraries). But the main thing is he's still developing it and it has halfway decent regular expression parsing for it's rules and I'm thinking a more generalized implementation of what he did would make a good start on your idea (a good idea I think).
Mycroft
https://signup.leagueoflegends.com/?ref=4c3ed6600b6ea
That's true and very Score:5, Insightful. The only two things which should not be in the application's own directory (i.e. in standard /opt/application_name on Unix)
are configuration files and public libraries.
After all, why would anything besides the config files,
libraries and executables should be in any fixed place?
Oh, yes, the executables,
it's good to have them in PATH without
having every program add its own dir to PATH.
So anyway, there are only three things
which should not be in the application's own directory,
but everything other than configuration,
libraries, executables and manual pages,
that's four, four things,
just four things,
configuration files,
libraries, executables, man pages and
logs, the five things,
the only five things which could be in a central place are
configuration files,
libraries, executables, man pages, logs
and temporary files, I mean six, that's six things,
libraries, executables, man pages, logs,
temp files and pid files,
seven, only seven, the only seven things
are temp files, pid files, lock files...
Amongst the things...
Amongst those directories...
are such elements as fear, surprise.... I'll come in again.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
The main problem I have with Apple, Microsoft, KDE, Gnome, and just about every other desktop visionaries are that they want to make the easy stuff easier but they rarely make the hard stuff easier. This is partly why users can get themselves into trouble but have to pay someone to get them out of it. Just today I talked to a guy that is going to bring me his computers to remove all the spyware crap from.
Linux can, and does, embrace and extend technologies but it lacks the same force because the code is open and Linux doesn't have nearly as big a slice of the marketshare. It did conquer the server market because of this embrace, extend, and expose concept though and in time it'll do the same on the desktop. I don't think KDE or Gnome are going to do that though. Not without a radical change in vision.
I did have a lil shell wizard program that was similar to the GUI shell commands + pipes idea I mentioned earlier. I canned the project mostly because NOBODY found it interesting other than me and also because I really wanted it more tightly intergrated with the desktop than I had time to do. IMO lack of user feedback is a big problem. If nobody uses a program I make or tells me what changes need to be made then I just won't bother trying to help them.
I think I agree that the desktop is something of an idiot box interface and the command-line is sort of a power users interface and the two do a very poor job of merging gradually together.. making a spectrum of accessibility to the system.
Never heard of that newsreader.. but then I usually use custom programs to access usenet. I've been thinking of writing a full custom mail client because gradually I've been writing most the bits of one. It might be interesting to add news support in. Any special features Gravity has that make it more accessible or powerful? Just reg expressions?
Actually though I already have some of the tools I'd like to build into the desktop.. a special moduler suite that collects data and makes it searchable. I've been working on making it into a P2P network (just for searching.. no files transfered) and it'd be cool if every Linux desktop had it intergrated. It can search pretty much any type of data.. you just have to install a module for that particular use.
At what price learning? At what cost wisdom? The price is a man's peace of mind, and the cost is his life.
Sounds like you've got some of the bits and pieces needed to make some needed improvements. Other than putting them up on sourceforge and or tossing a few messages on the right mailing lists I'm not shure what else to suggest on getting them used.
Yeah, makeing the hard stuff easy rather than just making the easy stuff easier would be an improvement.
Gravity is still just windows at the moment. The regular expressions are merged into a conditional expression/booleen evaluation system, almost a scripting language, that has a rather decent interface for applying. It doese a fairly good job with multi-part posts and handling crossposted messages. plus it's got functions for handling decode jobs and of course the various encoding schemes for binaries. But to be honest it's main advantage for me is it's whole interface and layout suits the way I think.
A well organised and gradual shift from noob to power user in various features and settings, etc. should be a design goal in any software of non-trivial complexity/functionality. It's one area where much of Linux need improvement imho.
That and consistancy, at least out of the box. Just about everyone coding for linux seems to have a different idea about look and feel for thier apps and that tends creat confusion and cognitive disruption. At least with the high theme-ability of many linux desktop aps and even desktops it's possible to reduce this at the distro level. Though it won't help much with deciding what kinds of things go under which menus (do 'options' go under thier own menu, under file, under edit, under tools, etc. and what counts as options, as preference.) that all software seems to suffer regardless of os.
On problem is that alot of useability and interface guidlines come out of studies and research by experts in narrow fields hired by the likes of Apple and Microsoft. Not exactly a common forte amoung open source coders, or even coders in genera. Nor is running focus groups and other such testing a 'sexy' thing for most software developers.
Mycroft
https://signup.leagueoflegends.com/?ref=4c3ed6600b6ea