if you have that adding something would be just doing a

dsh -g office $deploy stuff

at least that is what’s the best and proper solution. since rsync will not track files, won’t let you update/cleanup properly.

All distributions let you maintain systems in a quite clean way once you spend _once_ the time to setup properly a local repository.

Even with Java and python the model you are proposing doesn’t work that well.

This is likely for small businesses where the people writing the software are also the people buying using (I really don’t know how I made that typo) the software, where every machine that is purchased is purchased individually because the business does not buy in bulk because it need not do so (and it would be a waste of money), and where the next system that is purchased for something is whatever the least expensive thing is, because the operating system itself is supported on just about any easily obtainable platform. It would seem to be to be extremely unlikely to have a use outside of that environment, much like signed binaries would not (but would require modifications in all the same places of the toolchain as FatELF to be truly useful).

Right now _the_ way to install something on a distribution is calling

$pkgmanager $installcommand name

and be done with it (or using a graphical front-end with more or less the same immediate fruition). That’s the simplest way for an user to get his software.

setting up a repo for custom packages is quite easy at least on the distributions I know, same getting a package for a target system using cross-development tools.

I’m not even starting to consider why technically the FatELF idea is wrong as implementation or how the whole proposal had been mismanaged, in my opinion it is completely pointless as usecase.

If all that were published were just a Doxygen-style API documentation for an access library, then yes, it might be more difficult than it needs to be. However, that’s not the case; we have a fully free software (GPLv3 even) client that we can use to test against a server. Anyone who can read Python (and that’s a *lot* of people) can read the code that goes into the U1 client and write a specification based on the code, even doing something like writing it in the style of an RFC so that it can be made easy to implement. Take, for example, the HTTP standard which can be easily turned into code for either a client or a server because it’s written decently.

It should also be possible to read the client code and create a skeleton server implementation that is stubbed out and just needs to be filled in, where it returns errors for things that aren’t implemented. As I mentioned in my post itself, I have not had the time to do it, though if I *did* have the time to do it, I likely would be working on it already. It would be nice, as I could use a solution for storing close to a terabyte of synchronized data using the type of technology that is built into U1. Alas, near real-time synchronization of that data isn’t a high priority at this time, and weekly rsyncs will have to suffice.

However what you do here is sort of throwing a stone and hiding your hand.

Developing client-server apps its never easy, and you need to take into account that having the source code is only half of the equation. One needs to get familiar with it, and keep shooting to a moving target as the original software maker keeps adding stuff to their server implementation.

I would make the case for Canonical releasing the server side too, so people like I, who will never ever pay for anything online that I can make myself for free on my own server, can use it, and at least trust it so to recommend other people (willing to pay for the service) to use the service.

In the mean time, I’ll stick to rsync + ssh.

A few issues that I have with your comment: you say that “I find that the best way to speed up a computer is by defragmenting it.” This sounds like the sales pitch for a lot of fly-by-night Web sites that claim to fix up your computer and make it run faster. It is vague, and it is so simplistic as to be incorrect. Now, do not take too much offense to that—I suspect that Windows running on FAT or NTFS is probably all that you know and so maybe you feel that your statement is absolutely correct. If that is the case, do read on.

Microsoft’s operating systems know how to speak to two major filesystems, the File Allocation Table (FAT) filesystem and the New Technology File System (NTFS). The FAT filesystem is a very simple filesystem with a fixed layout, and it comes in 12, 16, and 32-bit sizes (e.g., FAT12, FAT16, and FAT32). These filesystems only natively support short file names and are easily subject to filesystem corruption, as the filesystem family’s core design did not change much since 1980 and were not intended for the highly multitasking environments that it was used in near its end-of-life as a primary hard disk filesystem. Also, it was subject to extreme fragmentation, as DOS and Windows did not take any measures to try to proactively keep files from becoming fragmented.

Now, in modern versions of Windows which use NTFS as their primary filesystem, file fragmentation is not (as much) of a problem. It still of course is a problem, because it needs to be periodically defragmented. However, where one would typically recommend that a FAT16 or FAT32 filesystem be defragmented once a week, one can today easily recommend that NTFS filesystems on average consumer Windows systems can be defragmented once per month, or even once every other month. There is no harm in doing it more frequently than that, but it is not typically necessary to do so in order to keep filesystem performance up.

Now, to change gears a little bit: there are other filesystems and operating systems out there, and so your statement is perhaps most correctly stated thus: “… the best way to speed up an FAT or NTFS filesystem is to defragment it regularly.” Also, I do not run with FAT or NTFS on my hard disk as a primary filesystem, as I use GNU/Linux, and today I use both ext4 and btrfs for filesystems. I have been using the ext2/3/4 family for years, and not one have I actually run into a situation where file fragmentation was a problem on such a filesystem. Granted, for file fragmentation to be a problem on ext2 or ext3 you had to be running very heavy loads with a great number of users.

I find that the best way to speed up a computer is by defragmenting it.

You can use the Windows Defrag Tool that can speed up your computer by miles, I recently ran it on my five year old Windows XP Machine and now it flys!

Saves you money as you don’t have to buy a new computer.

There are, as oiaohm mentioned, other portable userspace driver implementations for various types of drivers. I’m going to have to look into them and perhaps write up on what I find next.