OS Upgrades Powered By Git
JamieKitson writes "The latest Webconverger 15 release is the first Linux distribution to be automagically updatable from a Github repository. The chroot of the OS is kept natively in git's format and fuse mounted with git-fs. Webconverger fulfills the Web kiosk use case, using Firefox and competes indirectly with Google Chrome OS. Chrome OS also has an autoupdate feature, however not as powerful, unified & transparent as when simply using git."
They describe it as "automagic", SO I HAVE NO #$%&*(*+&% INTEREST IN IT!
Ever! Arg!
Yet Another Update Manager.
Replacing one transport with another isn't innovative enough to warrant the attention. You could use torrents under YUM or APT, you could use GIT, SVN, or any of a number of change management tools as a means to tell the client which updates to subscribe to and install.
But I doubt any such approach will ever see critical mass, just because the two big players (Debian/Ubuntu and RedHat/RHEL) already have perfectly usable tools. You'd need some serious whizz-bang new features to justify changing those tools, and the article doesn't suggest anything that can't be done already with existing technology.
Change for the sake of change is pointless; there has to be a benefit big enough to justify the change, and I don't see that in the write-up.
I do not fail; I succeed at finding out what does not work.
Chrome OS also has an autoupdate feature, however not as powerful, unified & transparent as when simply using git.
"clever" differential updates usually work this way (Chrome browser uses it or used it back in the day):
And Git has can not do that yet, because it uses diff + deflate, having far less scope than, e.g. LZMA with 500MB dictionary (requiring 5GB of memory for compressing it is acceptable if it is done just once per version).
Uhm, and how is it any worse than in every other major distribution or operating system?
My first program:
Hell Segmentation fault
Commits can be signed and verified ?
My company is migrating to git for all of our versioning control. I got to be the person to fly to the UK and get everyone up to speed on it. I knew it was British slang but not the full connotation of such.
I think you Brits need to make the next generation versioning system and call it fucker/bastard just to get us back.
I couldn't imaging standing up in front of my managers manager. "Well yeah, we're moving to bastard next. Bastards not too hard to use. You just type 'bastard clone'...."
Git has integrity checking built into it already, presuming you trust the source. The only way this can happen is if someone gets access to the git repository and commits malicious code. No project is safe from that case.
MidnightBSD: The BSD for Everyone
It's sad that no one picked up on the IMHO biggest snafu: the chroot is mounted using git-fs. Performance-wise it'll suck donkey balls just because of that. Just think of it: every page mapping for those executables has to go through userspace! Whoever thought of that was a real whiz, sigh.
If I were serious about it, I'd work on getting gitfs implemented natively in the kernel. Using fuse could be a proof-of-concept while the kernel driver is being implemented. I just hope that git stores its database with files still being files, because at least then the kernel driver could be, pretty much a filter driver that only rewrites file paths. Otherwise it'll have to be a full-blown filesystem driver with all the inefficiencies of using what amounts to multiple loop devices as its backend.
A successful API design takes a mixture of software design and pedagogy.
Nevermind, set memory to 1GB, works.
Crimey