| |||||||||||||
I don't use GNOME, but...I don't use GNOME, but...Posted Jan 27, 2010 16:47 UTC (Wed) by drag (subscriber, #31333)In reply to: I don't use GNOME, but... by dskoll Parent article: Stormy Peters: What should the GNOME Foundation accomplish in 2010?
might if GNOME tried to be more UNIX-like
(Log in to post comments)
I don't use GNOME, but... Posted Jan 27, 2010 17:09 UTC (Wed) by dskoll (subscriber, #1630) [Link] There is really no such thing as a desktop behaving more Unix-like. Sure there is.
You don't 'minimize windows' you 'iconize' them. The term is iconify and it makes the same amount of sense to me as minimize. (ie, none.) The window management sucks. That's your opinion, nothing more. There is no power management features to speak of. There is no notification system or reasonable IPC for applications to use besides sockets. These have all successfully been built on top of a UNIX-like base without abandoning the UNIX philosophy of small, cooperating programs that each do one thing well. There is no reasonable file manager. There are lots of reasonable file managers. Take your pick. I happen to hate all file managers anyway, so whichever one GNOME picks for that task doesn't matter to me. You are confusing the term UNIX-like with similar to previous UNIX desktops. That's not at all what I meant. Evolution does suck, but other IMAP applications are no shakes either.. so far the most decent one I can find is actually 'mutt'. I'm fairly happy with Thunderbird. The It's All Text plugin integrates it with my favorite text editor... a perfect example of the UNIX philosophy.
I don't use GNOME, but... Posted Jan 27, 2010 19:00 UTC (Wed) by drag (subscriber, #31333) [Link] Include man pages for all applications.So far Microsoft has done a much better job of doing this (providing documentation) for the desktop then anything I've seen come out of a Unix tradition. Make programs that involve editing large amounts of text capable of calling an external editor. IBM got this right in the early 1960's with System-360, for crying out loud! Well the 360 is not really Unix is it? Then again it does not really use the concept of files and directories either... In fact it's completely a alien OS to Unix in every way imaginable. Use standard terminology that's been around since the early 1970's instead of introducing inconsistent terminology. Like what? MiBs? Use human-readable configuration files under the hood. (You can use whatever flashy GUI configuration editor you like for neophytes.) A flat directory system containing hundreds of files, each using different formats and different naming conventions is not 'human readable'. Individually; yes, but collectively; no. It's inhuman, actually. Gconf is better then most things I've seen. Directory trees containing individual text files with keyword-value pairs is standardized and easily editable. Editing gconf by hand using Vi is a hell of a lot easier then trying to figure out most rc files. Too bad about that lack of documentation, of course. It's what kills it. These have all successfully been built on top of a UNIX-like base without abandoning the UNIX philosophy of small, cooperating programs that each do one thing well. Really? Why is nobody using these systems then? Got any real examples? Because while it's entirely possible you have something in mind that I am unaware of, I have no clue what it is and I have not seen a Unix system that is successful at it. I'm fairly happy with Thunderbird. The It's All Text plugin integrates it with my favorite text editor... a perfect example of the UNIX philosophy. Thats funny because Thunderbird comes almost completely from a Windows/DOS- based tradition. Also it's a monolythic application with it's own widget set and rendering system and shares very little functionality or code with other applications in your system, except Firefox. Very un-Unixy. Also plugin systems and extensions to applications probably existed in Windows/DOS desktop applications first. Except maybe Emacs. I suppose emacs had the same sort of functionality. Except that comes from a LISP machine background and not Unix. There are lots of reasonable file managers. Take your pick. I happen to hate all file managers anyway, so whichever one GNOME picks for that task doesn't matter to me. Not in any Unix system I've ever seen. The closest to 'traditional' you can get is 'Midnight Commander' 2-pane-style managers (there are a whole group of applications similar to that that were popular) and that is a unabashed clone of a popular proprietary DOS application. You are confusing the term UNIX-like with similar to previous UNIX desktops. That's not at all what I meant. I think that your just confused about the situation. Not trying to be offensive so don't take it the wrong way... it just seems to be a normal thread of thought with discussions around Linux desktops. There is no UNIX-like anything with pretty much everything you've talked about and shown examples of liking. I think that besides some general system design and programming approaches there is nothing in the Unix tradition that really helps out in making a quality desktop experience. There are just features that you want that sound actually nice to have. Especially the documentation thing.
I don't use GNOME, but... Posted Jan 27, 2010 19:14 UTC (Wed) by dskoll (subscriber, #1630) [Link] So far Microsoft has done a much better job of doing this (providing documentation) for the desktop then anything I've seen come out of a Unix tradition. The proprietary UNIXes (eg, Solaris) were pretty diligent about having a man page for everything. And AFAIK, Debian's policy requires every program that would be found on a normal PATH to have a man page. (Though some Debian man pages are stubs, alas.) My mention of System 360 was simply to show how designers got this right 50 years ago. There's no excuse for GNOME to continue to get it wrong in 2010.
I don't use GNOME, but... Posted Jan 27, 2010 19:30 UTC (Wed) by cmccabe (guest, #60281) [Link]
> The 'Unix-like' way of doing things is to have a clipboard that makes zero sense.
In what way does the unix clipboard make "zero sense"? Not trying to troll, I just don't understand your point.
> The is no panel. There is no reasonable file manager.
From my vague memories of fvwm, fvwm2, and twm, I remember a lot of panels.
> There is no power management features to speak of.
What does this have to do with GNOME or x11?
> You have a crapload of .*rc files that are arbitrarily made up with unique
As opposed to a crapload of registry entries that are arbitrarily named with unique and completely undocumented behavior. If you've ever run regedit.exe then you know what I'm talking about. The only "advantages" of the registry are that you can't grep it, can't make it read-only, and can't back it up without special tools. Oh, and since it's a giant binary file, it can get "corrupted." That's what happens when you reinvent the filesystem, poorly.
Anyway, the user doesn't care how his preferences are stored. He just cares that there is a reasonable GUI to change them. I agree that UNIX lagged in this area in the past, but GUIs to edit .rc files are hardly a radical new idea that UNIX never had.
> If you want Evolution to behave more like 'Mutt' or 'Pine' or whatever
Yeah, Evolution and Thunderbird both kind of suck. Evolution more so.
I think everyone just gave up on desktop clients and started using gmail for their personal mail. And for work mail, the volume of messages is so low that I can use T-bird.
I don't use GNOME, but... Posted Jan 28, 2010 0:25 UTC (Thu) by SEMW (guest, #52697) [Link]
> The only "advantages" of the registry are that you can't grep it, can't make it read-only, and can't back it up without special tools. Oh, and since it's a giant binary file, it can get "corrupted."
There are enough good arguments against a registry, and reasons why the advantages are outweighed by the disadvantages, that not making them in favour of making the rather silly claim that it has *no* advantages *at all* (and sarcastically listing its disadvantages as "advantages") takes away rather than adds to your point.
So in the interests of balance, I'll play devil's advocate and throw out a couple of advantages of a registry database system:
- Key-level access controls, which can be done with text files only by having only one key/value per file (which has its own disadvantages)
- All the atomicity, transactioning, and other consistency advantages that a database & dbms give you
- Strongly-typed data
- Changes are done through a standardised API, which makes makes a lot of stuff, such as centralised administration, easier
- .reg files, gconftool, etc. have no real equivalent in text files with unstandardised syntax
A lot of those aren't only advantages of a *binary* registry -- e.g. the gnome registry, gconf, uses xml files as a backend by default, but still has a standardised API, strongly-typed data, etc. The arguments between using e.g. xml as a backend and a binary database backend are probably fairly standard, and other people will be able to argue either way better than I would (but it is a tradeoff, e.g. between ability to make manual edits in an emergency as against parsing speed).
I don't use GNOME, but... Posted Jan 28, 2010 7:03 UTC (Thu) by cmccabe (guest, #60281) [Link]
I enjoy playing devil's advocate, too. Let me try to respond. :)
> Key-level access controls, which can be done with text files only by
I've never, ever come across a situation where I wished I could make one half of a configuration file editable by one user and another half by another.
In the situations where it might be even of theoretical interest, the software designers always split the configuration into multiple files, or provide #include-like functionality.
> All the atomicity, transactioning, and other consistency advantages that a
Atomicity is a solved problem. Just create the new config file as a separate file, then use rename() to get either the old or new file. Every filesystem that I know of has this semantic with rename (yes, I know it's not strictly in POSIX.) Every major UNIX text editor (vi, emacs, etc.) uses the rename() trick by default.
Transactioning is a solved problem because... you do make backups of /etc, right? Or you use btrfs with snapshotting.
It might be interesting to have a registry that had something like a foreign key constraint in SQL. (If X is set, then Y can't be set, etc.) The problem with schemes like this is that they tend to assume close cooperation between the maintainers of different projects. One config file per-daemon or service puts the responsibility squarely on the package maintainer's shoulders. With foreign-key constraints that could span packages, who has the final responsibility for fixing things?
Also, if the constraint is violated, what do you do? Silently modify the user's configuration according to your own whims? shutdown -h? Or just add to the syslog spew?
> Strongly-typed data
This is probably the strongest argument in favor of a registry. Being forced to use getter and setter functions prevents you from writing your own parser, which you'll probably screw up.
The rebuttal is that good programmers never write their own parsers from scratch. They use tools like lex and yacc to generate parsers which are type-safe and correct. Or they use a canned format like XML or the Python ConfigParser format.
The more detailed rebuttal is that true type-safety would require the ability to extend the registry with arbitrary datatypes. Sure you have string and uint32, but will you allow me to store my FtpUser object? If you won't, I'm still going to be doing something that smells a lot like parsing.
> Changes are done through a standardised API, which makes makes a lot of
There are tools like "Chef" that provide centralized management for unix config files. On the other hand, there are no such tools that I'm aware of for the Windows registry, unless you want to call "regedit" such a tool. I'm not aware of any for the gnome registry except for it's own registry editor dialog, and... Gnome itself. The reality is that one program cannot understand another program's configuration, no matter how it's stored or parsed, without someone putting work into integrating the two projects. Centralization and integration have nothing to do with technology, and everything to do with politics and management.
Since I'm being a completionist, let me point out another thing. You forgot to mention another argument against text file configuration: configuration file size. A set of (binary) registry entries can be parsed more quickly than a large text file.
This actually became a real issue in the samba program. Some users had extremely large configurations that were taking a long time to parse when the daemon was started. The samba team solved it by providing a (non-mandatory) facility to compile the config file into a binary representation.
I don't use GNOME, but... Posted Jan 28, 2010 15:03 UTC (Thu) by nix (subscriber, #2304) [Link] Since I'm being a completionist, let me point out another thing. You forgot to mention another argument against text file configuration: configuration file size. A set of (binary) registry entries can be parsed more quickly than a large text file.This became a real issue in KDE, as well, long ago; but taking the hit once per session is quite acceptable. So we have canonical textual configuration files, a fast-to-read binary cache in /var/tmp/kdecache-$USER/ksycoca (which can be completely nonportable, mmap()ed by its users directly), and a daemon which watches the textual configuration files and regenerates the cache whenever they change.
I don't use GNOME, but... Posted Jan 31, 2010 0:37 UTC (Sun) by cortana (subscriber, #24596) [Link]
> Atomicity is a solved problem. Just create the new config file as a separate file, then use rename() to get either the old or new file. Every filesystem that I know of has this semantic with rename (yes, I know it's not strictly in POSIX.) Every major UNIX text editor (vi, emacs, etc.) uses the rename() trick by default.
Doesn't that blow away the file ownership, permissions, ACL and extended attribute information?
I don't use GNOME, but... Posted Jan 31, 2010 9:35 UTC (Sun) by anselm (subscriber, #2796) [Link] In the general case, yes. In the case of config files this is rarely an issue -- if you can do »rename()« on the original file (write to the parent directory, really), you're usually in a position to set up the permissions etc. of the new file to match the old, and it's not as if there are lots of obvious choices for these, anyway.
|
|||||||||||||