Shuttleworth: No default GNOME Shell in Ubuntu 10.10 (The H) [LWN.net]

Shuttleworth: No default GNOME Shell in Ubuntu 10.10 (The H)

Posted May 7, 2010 8:23 UTC (Fri) by dgm (subscriber, #49227) [Link]

Ubuntu "raison d'être" is being for the mass audience (for human beings as they put it). And it's all good if they succeed. If that means "dumbing" the system down, so be it. This is not going to take Debian, Fedora, Slackware or Gentoo away from us.

I personally think it would be a lot better if all the people using Windows started using a ultra-dumbed-down UNIX, as this brings them much closer to a sane OS.

And of course, most of us also benefit from a system that "just works", from time to time. My netbook, for instance, works wonderfully with a minimal effort thanks to the "dumbing down".

Shuttleworth: No default GNOME Shell in Ubuntu 10.10 (The H)

Posted May 7, 2010 11:05 UTC (Fri) by jonth (subscriber, #4008) [Link]

I personally think it would be a lot better if all the people using Windows started using a ultra-dumbed-down UNIX, as this brings them much closer to a sane OS.

They already can. It's called OS X.

Shuttleworth: No default GNOME Shell in Ubuntu 10.10 (The H)

Posted May 7, 2010 12:42 UTC (Fri) by ndye (subscriber, #9947) [Link]

I personally think it would be a lot better if all the people using Windows started using a ultra-dumbed-down UNIX, as this brings them much closer to a sane OS.
They already can. It's called OS X.

Ubuntu on used hardware tends to feel ... affordable.

Shuttleworth: No default GNOME Shell in Ubuntu 10.10 (The H)

Posted May 7, 2010 20:12 UTC (Fri) by flashydave (subscriber, #29267) [Link]

I wish a larger percentage of systems I deal with did "just work". Whilst I agree some irksome things are now very usable out of the box (WPA, audio, mass storage spring to mind) I increasingly have problems with XOrg, boot failures and network config issues. OK I have lots of experience and can sort out my own problems (even if it can take a lot of time).

What I find difficult is defending Linux's reputation when colleagues (most of whom are professional software engineers) have been convinced by me to try Linux out and have a worse experience than they would have had with Windows.
For example in the last week since 10.04 was released I have had
a) Three examples of not being able to obtain the same X resolution as Windows on the same hardware (and a myriad of mis-information on the forums meaning they cant simply solve the problem themselves).
b) Having a machine that wouldnt boot after upgrade (because it cant find the disk UUID)
c) Two cases where the install CD wouldnt boot on hardware that earlier versions (and things like Knoppix) handled fine.
d) A case where the move to NM with a system someone required remote access wont work out of the box because of the need for login first.
e) A situation where a VM bridge network setup got trampled via the upgrade to 10.04
f) Someone trashed their whole machine data and all via an innocent upgrade. (This might have been salvageable with help but the victim couldn't deal with the problem themselves and tried a reinstall).

I'm not sure how much thats buggy behaviour or lack of QA and how much its a consequence of trying to simplify the users experience and then failing in more complex usage scenarios.

Shuttleworth: No default GNOME Shell in Ubuntu 10.10 (The H)

Posted May 7, 2010 9:56 UTC (Fri) by Frej (subscriber, #4165) [Link]

* xorg.conf never went away. Yes the hal fdi files were suboptimal in syntax (xml). But the semantics are considerably better and the hal FDI solution was never used in a LTS release. See https://wiki.ubuntu.com/X/Config (xorg.conf.d). (Not that canonical did any of the work).

* I think it's a bit short sighted to say that network manager automaticly gets everything wrong. If you don't like it, just remove it? And you never stated what it got wrong.

Frankly, the group who repeatly spreads the 'dumbing down' rants, just seem to be anoyed at change. Ie, they have to check a box instead of editing an .conf file or that the .conf file changed format or moved elsewhere. Yes it would be nice with automatic migration, but somebody has to do it. You complain, instead of figuring out what has actually changed. So maybe step back and just use RHEL/LTS releases instead if it's change is so painfull?
Half year release are development snapshots, and will have weird changes all over.

PS: Technically inclined people often believe they know better because they have the nescessary technical confidence. And yes, that applies to me aswell. Challenge your assumptions.

PPS: sorry for the spelling errors... ;)

Shuttleworth: No default GNOME Shell in Ubuntu 10.10 (The H)

Posted May 7, 2010 10:39 UTC (Fri) by michaeljt (subscriber, #39183) [Link]

> Frankly, the group who repeatly spreads the 'dumbing down' rants, just seem to be anoyed at change. Ie, they have to check a box instead of editing an .conf file or that the .conf file changed format or moved elsewhere.

At least the part about "no xorg.conf by default" might be read as a complaint about the PCI bus and monitor EDID information dumbing down the configuration process compared to ISA. On the other hand, I do feel a bit sad when things can only be configured using a checkbox, not a .conf file. I much prefer it when changes to the right .conf file will be picked up by the checkbox without fuss and vice-versa.

Shuttleworth: No default GNOME Shell in Ubuntu 10.10 (The H)

Posted May 7, 2010 15:31 UTC (Fri) by cry_regarder (subscriber, #50545) [Link]

Especially when you can't get to the check box until the configuration is right, but you can't make the configuration right until you get to the check box.

The big frustration for me now is that TTPs (tactics techniques practices) developed over 15 years of using unix are rapidly becoming useless. I used to be able to learn the guts of a config file and that knowledge would hold you in good stead for a decade. Now I have to learn three different GUI tools that don't quite do the job, that change every 5 months, and that override the config file at will.

I try to tell myself that this is good. It means things are finally getting attention after decades of inattention. I tell myself that if It gets to much, I'll just switch to RHEL 6 when it comes out and then I don't need to worry for another 7 years :-)

Cry

CAPS -> Control

Posted May 7, 2010 19:59 UTC (Fri) by pflugstad (subscriber, #224) [Link]

My main problem is that the changes with xorg.conf go beyond X.

As an example, try and configure your console to remap Caps Lock to Control. Used to be you edited the kmap file and just changed it there. Took about 5 minutes to figure it out.

The /etc/default/console-setup file lets you pass "ctrl:nocaps" another utility that generates a kmap file for you. I won't go the fact that "ctrl:nocaps" seems a bit nonsensical to me(ummm... why not something like, say, caps:control), but why propagate X stuff into the console setup?

And don't get me started about the GUI tool to change this - what genius thought that the "Regional & Accessibility" settings panel in KDE would be the right place for this. You think... maybe... the KEYBOARD settings panel would be a bit more appropriate? And I can't even find a GUI tool for doing this in XFCE.

Sigh... grumble... maybe I'm just not getting something, but the above just seems WAY too convoluted to be sane, for no gain.

CAPS -> Control

Posted May 7, 2010 20:39 UTC (Fri) by sfeam (subscriber, #2841) [Link]

Not to mention that although there are 9 different options for CapsLock behaviour that can be selected in the GUI, this isn't one of them. Instead you have to look under the "Ctrl key position" menu.

CAPS -> Control

Posted May 7, 2010 21:21 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]

this is exactly what I am complaining about.

it should be that you can edit the keymap file like you used to, and the higher level tools will take this into account when you use them.

unfortunately these tools treat the keymap file as an output-only file

what's worse, the desktop environment then treats the intermediate config file as an output-only file, so you end up having to try and figure out what GUI function you need to modify one file to send the appropriate instructions to another program to modify a different file.

CAPS -> Control

Posted May 13, 2010 13:27 UTC (Thu) by anton (guest, #25547) [Link]

My main problem is that the changes with xorg.conf go beyond X. As an example, try and configure your console to remap Caps Lock to Control.

You mean that the following no longer works (it does in Debian Squeeze)?

[~:72682] cat ~/.xmodmaprc 
clear lock
keysym Caps_Lock = Control_L
add control = Control_L
[~:72683] grep xmodmaprc ~/.xsession
xmodmap ~/.xmodmaprc

CAPS -> Control

Posted May 13, 2010 15:21 UTC (Thu) by pflugstad (subscriber, #224) [Link]

I was talking about the console - no X Windows running.

CAPS -> Control

Posted May 13, 2010 15:43 UTC (Thu) by anton (guest, #25547) [Link]

I considered that you also might want to remap caps-lock outside X, but you mentioned xorg.conf, and that only affects X. So how did xorg.conf changes result in changes to the console configuration?

CAPS -> Control

Posted May 13, 2010 16:00 UTC (Thu) by nye (guest, #51576) [Link]

If I understand the OP correctly, he said that the move towards living without xorg.conf led to the keyboard configuration being pushed down into a lower layer, replacing the old way which affected the console with one that now only affects X.

Shuttleworth: No default GNOME Shell in Ubuntu 10.10 (The H)

Posted May 7, 2010 20:19 UTC (Fri) by flashydave (subscriber, #29267) [Link]

I agree and totally share your frustration with TTP's going obsolete. It also means I no longer look cool (as the local Linux Guru) when fixing friends systems with a quick edit or two with vi. Its now a case of "leave it with me and I will fix it by poking and hoping whilst you arent watching me"!!

Shuttleworth: No default GNOME Shell in Ubuntu 10.10 (The H)

Posted May 7, 2010 17:47 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]

you can still configure X with xorg.conf, it's just that in most cases you don't need to and so simply removing the file and letting the system autodetect things works.

network manager is a different situation. I agree that the idea of a network config manager that can only be managed with a GUI and only brings up interfaces after a user has logged in is a problem.

even worse than that is the project's maintiners attitudes that they don't care if a system works with other network configs, they think it's a good thing to break users machines if there is a hardware/driver issue rather than using known work-arounds to make users systems work.

for my work thinkpad it's bad enough that I resort to manually configuring the wireless when I'm traveling.

Shuttleworth: No default GNOME Shell in Ubuntu 10.10 (The H)

Posted May 7, 2010 18:18 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

The comments against NetworkManager should be considered obsolete. NetworkManager has supported system wide connections and a command line interface (cnetworkmanager and now recently nmcli) for quite sometime.

In Fedora 12,

https://fedoraproject.org/wiki/Features/NetworkManagerSys...

In Fedora 13,

https://fedoraproject.org/wiki/Features/NetworkManagerCmd...

Shuttleworth: No default GNOME Shell in Ubuntu 10.10 (The H)

Posted May 7, 2010 18:58 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]

note that fedora 13 hadn't been released yet, and 12 is only 6 months old.

It has been 6-9 months since I last messed with this and at that time the response to the comment was 'if you want a command line tool, go write one'

Shuttleworth: No default GNOME Shell in Ubuntu 10.10 (The H)

Posted May 7, 2010 21:48 UTC (Fri) by rahulsundaram (subscriber, #21946) [Link]

As I already noted, cnetworkmanager has existed for quite sometime. nmcli is fairly new but has been pushed as an update for Fedora 12 as well.

Shuttleworth: No default GNOME Shell in Ubuntu 10.10 (The H)

Posted May 7, 2010 18:33 UTC (Fri) by jspaleta (subscriber, #50639) [Link]

What?

I'm not having any trouble with the onboard wireless on my thinkpad using NM in the distribution I use on a regular basis. I think I hit 6 or 7 different wireless networks in town in a given week.. and then several more every time I get on a plane. I'm too cheap to pay for in-air wireless..but hotel, mcdonalds and barnes & noble wireless has worked like a champ for me where ever I go.

And I don't have any trouble using the legacy networking tools and scripts when have been updated to include an NM_CONTROLLED=yes/no variable. NM respects that setting for me on the distribution I'm using. Though I really don't need to use them much on my desktops and laptops as the system wide connections feature appears to be working fine for my needs to allow me to remotely login on machines from boot up. Perhaps a developer from your distro of choice needs to enhance its configuration file plugin to work better than it does?

I'm also looking forward to getting more familiar with the nmcli tool as it matures for server installations in conjunction with system wide connections. I don't make use of the more advanced work associated with juggling 3G data plans and metered services...but I appreciate that the work is important to other people.

-jef

Shuttleworth: No default GNOME Shell in Ubuntu 10.10 (The H)

Posted May 7, 2010 18:57 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]

network manager properly ignores interfaces that are manually configured, the other common package for the task (which I'm blanking on the name) doesn't.

I actually reported network manager problems with my thinkpad T61 and the answer that I got back was that it was a broken system and even though it would work if manually configured, the network manager maintainer refused to do whatever it would take to have it work from within network manager. The result is that it can connect, but will not reliably stay connected, requiring manual action to reconnect.

Shuttleworth: No default GNOME Shell in Ubuntu 10.10 (The H)

Posted May 7, 2010 15:45 UTC (Fri) by drag (subscriber, #31333) [Link]

> Whilst uniformity and consistency is a good goal this should not be at the expense of "dumbing down" to the lowest common denominator and losing the ability to customise or extract the advantages that Linux offers.

Dumbing down is GOOD.

Q) Do you know how much time I want to spend on configuring my video card or tweaking things so they work?

A) NONE AT ALL.

I don't want to fart around with asoundrc or xorg.conf or anything like that. I want to be able to safely manage WPA2 passwords without headaches. I want to be able to connect to network shares without having to run command line tools to scan networks and do crap like that. I don't want to su to root to enter passwords into wpa_supplicant.conf or figure out the horrifically bad wpa_cli utility or the chronically under-featured and poorly working Wicd weirdness.

Been there. Done that. All of it is a huge waste of my time and I don't care anymore. I don't want to care about Window managers or file managers or browsers or anything like that anymore. All of it is a time sink and it all prevents me from doing what I want to be doing and accomplishing what I want to accomplish.

A operating system is designed to run applications. If I am spending time with configuring the OS or the desktop environment rather then spending time working and getting things done with applications then that OS is wasting my time and is a barrier to efficiency.

Very literally:

If I want to I can take a default install of CentOS, strip it down, and configure it so that it can run completely off of a 1GB compact flash drive and run custom java applications. I can do this with Ubuntu, Debian, Mandriva, or whatever else.

This is easy for me. I've done it in the past. I did it last week. I did not have to recompile a single lick of code.. just through downloading RPMs and using Yum with chroot and a 200-line shell script I wrote.

To take it to a extreme: I can take a modern version of Linux and a modern version of Busybox and configure it, compile it, with NO patches, make a custom initrd-style envronment so that I can boot a 486-style machine from a single 1.44MB floppy drive and get a usable Unix-like environment.

There is nothing that Ubuntu or Centos or Redhat or anybody else that is anyway preventing me from doing this. And it's easier now then it ever was in the past.

I can run Ubuntu with KDE or LXDE or XFCE or not. I can get rid of PulseAudio without much headaches or use WPA_CLI instead of NM if I feel like it. This is not really rocket science or that difficult.

Of course all that crap is a huge waste of my time 99.99% of the time when it comes to dealing with a desktop. It's counter productive and all it does is make my life more difficult.

For what Ubuntu needs to do is to create a very strong default configuration and work on getting that to work as well as possible for the largest amount of people on the most commonly used hardware.

That's it.

Whether or not it makes it more difficult for people to delete PulseAudio off their hard drives or get rid of the 'Gnome-infected' version of Firefox or if it makes it slightly harder to run Fluxbox without N-M or anything like that is not any of their concern. It's still easy to accomplish that on Ubuntu if your a end user with a little bit of work if anybody still really cares that much about it.

> Also I am seeing frequent references to "reboot for these changes to take effect" whereas in most cases it is only matter of restarting a daemon or some other minor manual actions required to get something going. This is a slippery slope.

Because if your talking to end users it's a hell of a lot easier for you to give instructions THAT ACTUALLY WORK if you tell them to click 'reboot' rather then directing them go through and log out, log into a virtual terminal, restart a bunch of services, then logging back in. Rebooting is faster, much simpler, and gets the job done in a much more reliable way.

If your a 'expert' in Linux then avoiding reboots is trivial and Ubuntu should not have to hold your hand through the process. It's actually easier now with Ubuntu to avoid reboots even with dealing with kernel updates then it ever was before with any other Linux OS, (if anybody actually cares).

> Equally there is a risk that application writers start making too many assumptions about the environment they are programming for. Very much like "we only test with IE" type problems with web sites.

> One of Linux's real quality drivers is that programmers have learnt to cope with wide ranging circumstances (from embedded to mainframe, handling different installed kernel/libraries versions etc) and hence code defensively with adequate logging, well defined API's and minimised degree of interaction between sub-systems. This professional and modular approach keeps spaghetti code (and hence bugs) to the minimum, allows simpler debugging and stays true to the "do just one thing and do it well" philosophy.

Your having very very very large amount of conflicts in your statements there.

How can you seriously put 'Wide Rangine Circumstances (handling different installed kernel/libraries versions etc) in the same sentence as as "Well defined API's" and 'do one thing and do it well'???

To desktop application developers things like PulseAudio, Xorg extensions, GTK libraries, Gnome libraries, OpenGL 3.0, Python/C#/Vala Language support....

THOSE are the 'APIs'. Not goddarn Linux system calls.

To have them well-defined would mean that you document and test those APIs as well as making sure that those APIs are correctly supported and available on every Linux machine.

Making the application developers deal with the fact that you could have a unique configuration for every Linux user and that Ubuntu forces you to support all those different configurations in order to 'be flexible' then that means you are going to be forced to use shells scripts for launching applications, bundling huge amounts of libraries with your applications, and having huge amounts of spaghetti code to deal with all the different configurations you will run into. It makes programming for the Linux desktop buggy, time consuming, and difficult.

Not just for proprietary software, but open source software, home users, corporate users, etc etc.. it just makes the OS worse all around for Desktop usage.

Shuttleworth: No default GNOME Shell in Ubuntu 10.10 (The H)

Posted May 7, 2010 17:25 UTC (Fri) by SEJeff (subscriber, #51588) [Link]

Couldn't agree with you more in this comment. The only thing is that I think you should checkout febootstrap instead of yum + a 100 line shell script:

http://people.redhat.com/~rjones/febootstrap/

there are two ways to dumb down a system, one good, one bad

Posted May 7, 2010 17:52 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]

there are two ways to 'dumb down a systems'

the good way is the way that x.org is doing it. by making the system autodetect things, but still supporting a config file so that users can do the strange things if needed.

the bad way is what's happened in the network configuration space where options are removed so that there is no way for the user to do unusual things.

the best way is if the GUI/autodetection tools configure config files, and can cope with config files that have been manually edited. But doing so is very hard and very few applications support it (samba does a pretty good job here)

there are two ways to dumb down a system, one good, one bad

Posted May 7, 2010 19:13 UTC (Fri) by drdabbles (subscriber, #48755) [Link]

Things like this require config file parsing libraries. These libraries have existed for a VERY long time, but users don't want to have to learn a new config file format, and some application developers don't want to have another dependency for their app.

I, for one, think that a good .conf file framework to standardize configuration and access to that configuration would be a GREAT benefit to uses. Any application (gui or cli) that manages configs would be able to process the contents in a sane manner, and users could still modify files by hand if they so chose.

there are two ways to dumb down a system, one good, one bad

Posted May 7, 2010 19:18 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]

the apps already know how to parse the config files. it's not a matter of trying to force users to learn something new.

the problem is that the app developers don't want to have to do the hard work of having their config tool understand an arbatrary config file, so they take the easy way out, and if they have a config file it's a 'never edit this by hand' or write-only type of thing.

I'm nervous about calls for a standard config format/repository/tools. go too far down that road and you end up with the windows registry. we already have many apps too far down that road now.

there are two ways to dumb down a system, one good, one bad

Posted May 9, 2010 12:11 UTC (Sun) by nix (subscriber, #2304) [Link]

Isn't this the sort of thing that augeas is meant to solve?

there are two ways to dumb down a system, one good, one bad

Posted May 8, 2010 21:40 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link]

There is Augeus (http://augeas.net/) which allows to do precisely that. With it you can easily programmatically edit config files, without killing user comments.

there are two ways to dumb down a system, one good, one bad

Posted May 9, 2010 7:50 UTC (Sun) by tao (subscriber, #17563) [Link]

GLib already has a great API for managing configuration files (GKeyFile). For runtime configuration, GConf and its future replacement DConf are the obvious candidates.

Shuttleworth: No default GNOME Shell in Ubuntu 10.10 (The H)

Posted May 7, 2010 19:50 UTC (Fri) by cmccabe (guest, #60281) [Link]

You are attacking a strawman. Nobody is suggesting that making life more difficult for the end user is a good thing.

What we're arguing for is good software engineering.

A good software engineer understands that it is important to limit unnecessary dependencies and increase visibility into the system. It's also important to make software as simple as possible, because if you write overly clever software, you will not be able to debug it. It's important to break problems up into clearly defined layers of abstraction and resist the temptation to punch a hole through the abstractions when it seems convenient.

To make it less abstract: Assuming that the user will be running a certain window manager, when your program is not even graphical, is silly. Integrating core program functionality into a GUI is bad. You should rather write the GUI as a wrapper around the core program or library.

At a past job, I had to debug the GUI / NetworkManager / wpa_supplicant / linux kernel stack. We were tracking down unexplained wifi failures with WPA2 access points. It was extremely difficult to figure out what was going on. At that time, NetworkManager made ioctls to the hardware whenever it felt like it, bypassing wpa_supplicant and potentially giving conflicting directions. This was a layering violation. NetworkManager used DBUS to talk to wpa_supplicant and dhcpd. Rather than having a central event loop and queuing up DBUS responses, or using a central state machine, NetworkManager was completely asynchronous. A DBUS input would mutate some structures and arm a timer that triggered a DBUS output. Meanwhile, other messages could be processed simultaneously. There were tons and tons of mutexes and it was difficult to understand the dependencies between different parts of the program. Also, calls to dbus in NetworkManager were written in an extremely low-level style. The raw DBUS interface is extremely verbose. It often takes a whole page of code just to send a single RPC message.

It seems like NetworkManager has made some progress towards fixing some of these problems. It now has some command-line functionality, which might help whatever poor soul has to debug future problems. They also got rid of the raw ioctls from NetworkManager itself-- definitely a step in the right direction.

I can't help but wonder whether NM could have been designed in a much simpler way. For example, spawning one process per network interface and using mostly blocking RPCs would make things a lot easier. Using a higher-level language like python would probably be a good idea, too. Even in the ancient days, when 1 MB was a lot of memory, people realized the wisdom of making networking configuration scriptable.

Network Mismanager

Posted May 11, 2010 13:25 UTC (Tue) by pboddie (subscriber, #50784) [Link]

At a past job, I had to debug the GUI / NetworkManager / wpa_supplicant / linux kernel stack. We were tracking down unexplained wifi failures with WPA2 access points.

I feel very sorry for you. All I was trying to do, when I had to start debugging the networking from top to bottom, was to have a configuration where Kubuntu connected to the home network automatically. Doing this with KNetworkManager felt like a hack, but if it could remember the credentials and do the association by itself, then that would have been enough. Sadly, "connect to a known network by default" is not amongst the use-cases considered by the supposedly usability-conscious developers.

In the end, as I remarked on some other LWN post, I had to strip away the "helpful" stuff to get the basic, functional, Unix-style interfaces machinery to work. The sad thing is that a simple user interface on top of that would be better than the "must check the link status twenty times a second", overengineered, "daemons over D-BUS" solution.

Network Mismanager

Posted May 16, 2010 23:43 UTC (Sun) by cmccabe (guest, #60281) [Link]

I think that NetworkManager has improved over time. Like I said, there's now a built-in command-line interface (nmcli), and NetworkManager has stopped firing off ioctls alongside the programs it manages.

I think that the mechanisms for debugging D-BUS based systems have evolved more slowly than D-BUS itself. Hopefully this will improve too.

Shuttleworth: No default GNOME Shell in Ubuntu 10.10 (The H)

Posted May 7, 2010 20:46 UTC (Fri) by flashydave (subscriber, #29267) [Link]

Maybe I am expecting too much from one distro. Just like you I can and have customized systems where there is a specialized need but there are just too many situations where I am forced into "getting things working" which are because the distro is trying to double guess what you were trying to do and has either taken away or obfuscated the control or has made assumptions that are invalid.

There must be a compromise somewhere between the "Nanny State" where you are not allowed to step out of line and are simply "free to do as we tell you" and the freedom to use the system as you want - even if that means routine things take a little longer.

From your points on API's and the difficulty programming desktop applications I probably agree. I was actually thinking about lower level tools and libraries when I made my observations. At least a lot of the issues there have been resolved via tools like autoconf (if you can stomach it) or by using languages/libraries like Perl,Python,Java that abstract some of the issues away.